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Preface 



This volume contains the proceedings of the Fifth International Symposium on 
Functional and Logic Programming, FLOPS 2001, held in Tokyo, Japan, March 
7-9, 2001, and hosted by Waseda University. 

FLOPS is a forum for research on all issues concerning functional program- 
ming and logic programming. In particular, it aims to stimulate the cross- 
fertilization as well as the integration of the two paradigms. The previous FLOPS 
meetings took place in Fuji-Susono (1995), Shonan (1996), Kyoto (1998), and 
Tsukuba (1999). The proceedings of FLOPS’99 were published by Springer- 
Verlag as Lecture Notes in Computer Science, volume 1722. 

There were 40 submissions, 38 of which were considered by the program 
committee. They came from Australia (5), Belgium (Vs), Denmark (3), Egypt 
(1), France (V2), Germany ( 2 V 3 ), Italy ( 4 Va), Japan (5), Korea (1 V2), Mexico 
(1), The Netherlands (1 Ve), Spain (10 Ve), Switzerland (1), UK (1 Ve), and USA 
(1 V2). Each paper was reviewed by at least three, and mostly four, reviewers. 
The program committee meeting was conducted electronically for the period of 
two weeks in November 2000. As a result of active discussions, 21 papers (52.5%) 
were selected for presentation, which appear in this volume. In addition, we are 
very pleased to include in this volume full papers by three distinguished invited 
speakers, namely Gopalan Nadathur, George Necula, and Taisuke Sato. 

On behalf of the program committee, the program chairs would like to thank 
the invited speakers who agreed to give talks and contribute papers, all those who 
submitted papers, and all the referees for their careful work in the reviewing and 
selection process. The support of our sponsors is also gratefully acknowledged. 
In particular, we would like to thank the Japan Society for Software Science 
and Technology (JSSST), Special Interest Group on Principles of Programming, 
and the Association for Logic Programming (ALP). Finally, we would like to 
thank the members of the organizing committee, notably Zhenjiang Hu, Yasuhiro 
Ajiro, Kazuhiko Kakehi, and Madoka Kuniyasu, for their invaluable support 
throughout the preparation and organization of the symposium. 
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Herbert Kuchen 
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The Metalanguage AProlog 
and Its Implementation 



Gopalan Nadathur 

Department of Computer Science and Engineering 
University of Minnesota 
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gopalanOcs . umn. edu 
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Abstract. Stimulated by concerns of software certification especially 
as it relates to mobile code, formal structures such as specifications and 
proofs are beginning to play an explicit role in computing. In represent- 
ing and manipulating such structures, an approach is needed that pays 
attention to the binding operation that is present in them. The language 
AProlog provides programming support for a higher-order treatment of 
abstract syntax that is especially suited to this task. This support is 
realized by enhancing the traditional strength of logic programming in 
the metalanguage realm with an ability for dealing directly with binding 
structure. This paper identifies the features of AProlog that endow it 
with such a capability, illustrates their use and and describes methods 
for their implementation. Also discussed is a new realization of AProlog 
called Teyjus that incorporates the implementation ideas presented. 



1 Introduction 

The language AProlog is based on the higher-order theory of hereditary Har- 
rop formulas that embodies a rich interpretation of the abstract idea of logic 
programming [18]. Through a systematic exploitation of features present in the 
underlying logic, this language realizes several capabilities at the programming 
level such as ones for typing, scoping over names and procedure definitions, rep- 
resenting and manipulating complex formal structures, modular ly constructing 
code and higher-order programming. Our interest in this paper is in one specific 
facet of AProlog: its role as a metalanguage. 

The manipulation of symbolic expressions has been of longstanding inter- 
est and some of the earliest computational tasks to have been considered and 
systematically addressed have, in fact, concerned the realization of reasoning 
processes, the processing of human languages and the compilation and inter- 
pretation of programming languages. The calculations involved in these cases 
are typically metalinguistic and syntactic in nature and a careful study of their 
structure has produced a universally accepted set of concepts and tools relevant 
to this form of computing. An important component in this collection is the 
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idea of abstract syntax that moves away from concrete presentation and focuses 
instead on the essential relationships between the constituent parts of symbolic 
constructs. A complementary development has been that of languages that pro- 
vide programming support for computing with abstract syntax. These languages, 
which include Lisp, ML and Prolog amongst them, contain mechanisms that sim- 
plify the representation, construction and deconstruction of abstract syntax and 
that permit the implicit management of space relative to such manipulations. 
Effort has also been invested in implementing these languages efficiently, thereby 
making them practical vehicles for realizing complex symbolic systems. 

One may wonder against this backdrop if anything new really needs to be 
added to the capabilities already available for symbolic computation. The an- 
swer to this question revolves around the treatment of scope and binding. Many 
symbolic objects whose manipulation is of interest involve forms of these opera- 
tions in their structure in addition to the compositionality that is traditionally 
treated in abstract syntax. This is true, for instance, of quantified formulas that 
are considered within reasoning systems and of procedures with arguments that 
are of interest to programming language compilers. The conventional approach 
in these cases has been to use auxiliary mechanisms to avoid explicit reference 
to binding in representation. Thus, reasoning systems eliminate quantifiers from 
formulas through a preprocessing phase and compilers utilize symbol tables to 
create binding environments when these are needed in the analysis of programs. 
While such methods have been successful in the past, there is now an increas- 
ing interest in formal constructs with sophisticated and diverse forms of scope 
whose uniform treatment requires a reflection of the binding operation into ab- 
stract syntax itself. The desire to reason in systems different from classical logic 
provides one example of this kind. The elimination of quantifiers may either not 
be possible or desirable in many of these cases, requiring them to be explic- 
itly represented and dynamically treated by the reasoning process. In a similar 
vein, motivated by the proof-carrying-code approach to software certification 
[29], attention has been paid to the representation of proofs. The discharge of 
assumptions and the treatment of genericity are intrinsic to these formal struc- 
tures and a convenient method for representing such operations involves the use 
of binding constructs that range over their subparts. As a final example, relation- 
ships between declarations and uses are an important part of program structure 
and a formal treatment of these in representation can influence new approaches 
to program analysis and transformation. 

Driven by considerations such as these, much effort has recently been de- 
voted to developing an explicit treatment of binding in syntax representation, 
culminating in what has come to be known as higher-order abstract syntax [31]. 
The main novelty of AProlog as a metalanguage lies in the support it offers 
for this new approach to encoding syntactic objects. It realizes this support by 
enriching a conventional logic programming language in three essential ways. 
First, it replaces first-order terms — the data structures of a logic programming 
language — by the terms of a typed lambda calculus. Attendant on these lambda 
terms is a notion of equality given by the a-, j3- and /^-conversion rules. The main 
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difference in representational power between first-order terms and lambda terms 
is that the latter are capable of also capturing binding structure in a logically 
precise way. Thus, this enhancement in term structure endows AProlog with a 
means for representing higher-order abstract syntax. Second, AProlog uses a uni- 
fication operation that builds in the extended notion of equality accompanying 
lambda terms. This change provides the language with a destructuring opera- 
tion that can utilize information about binding structure. Finally, the language 
incorporates two new kinds of goals, these being expressions of the form 'ixG 
and D => G, in which G is a goal and T> is a conjunction of clauses.^ A goal of 
the form 'ixG is solved by replacing all free occurrences of a; in G with a new 
constant and then solving the result and a goal of the form T> => G is solved 
by enhancing the existing program with the clauses in D and then attempting 
to solve G. Thus, at a programming level, the new forms of goals, which are re- 
ferred to as generic and augment, respectively, provide mechanisms for scoping 
over names and code. As we shall see presently, these scoping abilities can be 
used to realize recursion over binding structure. 

Our objective in this paper is to show that the new features present in AProlog 
can simplify the programming of syntax manipulations and that they can be 
implemented with sufficient efficiency to be practical tools in this realm. Towards 
this end, we first motivate the programming uses of these features and then 
discuss the problems and approaches to realizing them in an actual system. The 
ideas we discuss here have been used in a recent implementation of AProlog 
called Teyjus [25] that we also briefly describe. We assume a basic familiarity 
with lambda calculus notions and logic programming languages and the methods 
for implementing them that are embedded, for instance, in the Warren Abstract 
Machine (WAM) [35]. Further, in keeping with the expository nature of the 
paper, we favor an informal style of presentation; all the desired formality can 
be found in references that are cited at relevant places. 

2 Higher-Order Abstract Syntax in AProlog 

A common refrain in symbolic computation is to focus on the essential func- 
tional structure of objects. This is true, for instance, of systems that manipulate 
programs. Thus, a compiler or interpreter that manipulates an expression of the 
form if B then T else E must recognize that this expression denotes a condi- 
tional involving three constituents: B, T and E. Similarly, a theorem prover that 

^ To recall terminology, a goal is what appears in the body of a procedure or as a 
top level query and is conventionally formed from atomic goals via conjunction, dis- 
junction and existential quantification. Clauses correspond to procedure definitions. 
While a free variable in a clause is usually assumed to be implicitly universally quan- 
tified at the head of the clause, there is ambiguity about the scope and force of such 
quantification when the clause appears in an expression of the form D => G. AProlog 
interprets the scope in this case to be the entire expression of which D => G itself 
may only be a part, and it bases the force on whether this expression is a goal or a 
clause. All other interpretations need to be indicated through explicit quantification. 
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encounters the formula P AQ, must realize that this is one representing the con- 
junction of P and Q. Conversely, assuming that we are not interested in issues 
of presentation, these are the only properties that needs to be recognized and 
represented in each case. The ‘abstract syntax’ of these expressions may there- 
fore be captured by the expressions cond(B,T,E) and and(P,Q), where cond and 
and are suitably chosen function symbols or constructors. 

Another important idea in syntax based computations is that of structural 
operational semantics that advocates the description of computational content 
through rules that operate on abstract syntax. For example, using > as an infix 
notation for the evaluation relation, the operational meaning of a conditional 
expression can be described through the rules 

B \> true T \>V 
cond(B,T, E) \>V 

B \> false E \>V 
ccmd(B,T, E) \>V 

Similarly, assuming that P — )■ P represents the judgement that E follows from 
a set of assumptions P, the logical content of a conjunction can be captured in 
the rule 



P — > P P — > Q 
P — > and(P, Q) 

Rules such as these can be used in combination with some control regimen 
determining their order of application to actually evaluate programs or to realize 
reasoning processes. 

The appropriateness of a logic programming language for symbolic compu- 
tation arises from the fact that it provides natural expression to both abstract 
syntax and rule based specifications. Thus, expressions of the form cond(B,T,E) 
and and(P,Q) are directly representable in such a language, being first-order 
terms. Depending on what they are being matched with, the unification oper- 
ation relative to these terms provides a means for constructing, deconstructing 
or recognizing patterns in abstract syntax. Structural operational rules translate 
directly to program clauses. The evaluation rules for conditional expressions can, 
for instance, be represented by the clauses 

eval(cond(B,T,E),V) eval(B,true), eval(T,V). 

eval(cond(B,T,E),V) eval(B, false), eval(E,V). 

Using these rules to realize interpretation may require capturing additional con- 
trol information, but this can be done through the usual programming devices. 

2.1 The Explicit Representation of Binding 

Many syntactic objects involve a form of binding and it may sometimes be nec- 
essary to reflect this explicitly in their representation. Binding structure can be 
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represented only in an approximate manner using conventional abstract syntax 
or first order terms. For example, consider the formula \fxP{x). This formula 
may be represented by the expression all{x,P{x)). However, this representa- 
tion misses important characteristics of quantification. Thus, the equivalence of 
\fxP{x) and VyP(y) is not immediately present in the ‘first-order’ rendition and 
has to be built in through auxiliary processes. In a related sense, suppose it is 
necessary to instantiate the outer quantifier in the formula \fx3yP{x,y) with 
the term t{y). The renaming required in carrying out this operation has to be 
explicitly programmed under the indicated representation. 

The availability of lambda terms in AProlog provides a different method for 
dealing with these issues. A binding operator has two different characteristics: 
it determines a scope and it identifies a particular kind of term. In AProlog, 
the latter role may be captured by a suitably chosen constructor while the ef- 
fect of scope may be reflected into a (metalanguage) abstraction. This form of 
representation is one of the main components of the higher-order approach to 
abstract syntax. Using this approach, the formula \fxP{x) might be rendered 
into the term (all Xx(P x)), where all is a constructor chosen to represent the 
predicative force of the universal quantifier; we employ an infix, curried notation 
for application here and below as is customary for higher-order languages, but 
the correspondence to the first-order syntax should be evident. Similarly, the 
program fragment 

lambda (x) if (x = 0) then (x - 2) else (2 * x) 
in a Lisp-like language might be represented by the term 

(abs \x(eond (eq x 0) (minus x 2) (times 2 x))) 

where abs is a constructor that identifies an object language abstraction and eq, 
plus, minus, 0, and 2 are constructors corresponding to the relevant programming 
language primitives. As a final, more involve example, consider the following code 
in a functional programming language: 

faet m n = if (m = 0) then n else (faet (m - 1) (m * n)) 

This code identifies faet as a function of two arguments that is defined through 
a fixed point construction. Towards making this structure explicit, the given 
program fragment may be rewritten as 

faet = (fixpt (f) (lambda (m) lambda (n) 

if (m = 0) then n else (f (m - 1) (m * n)))) 

assuming that fixpt represents a binding operator akin to lambda. Now, using the 
constructor fix to represent this operator and app to represent object language 
application, the expression that is identified with faet may be rendered into the 
following AProlog term:^ 

^ We are taking liberties with AProlog syntax here: the language employs a different 
notation for abstraction and all expressions in it are typed. In a more precise presen- 
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(fix Xf(abs Xm(abs An 

(cond (eq m 0) n (app (app f (minus ml)) (times m n)))))). 

The higher-order abstract syntax representation of binding structure solves 
the problems that were discussed relative to the first-order encoding. The formu- 
las \fxP{x) and VyP(y) translate to (all Xx(P x)) and (all Xy(P y)), but these 
are really the same terms by virtue of the understanding of a-conversion present 
in the metalanguage. Similarly, the instantiation of the quantifier in a formula 
represented by (all P) with the term represented by t is given simply by (P t); 
the correct substitution, with all the necessary renaming operations, is realized 
from this through the /3-conversion rule. The real power of this approach arises 
from the fact that the same principles apply to many other situations where 
binding is present. The encoding of programs, for instance, manifests an insen- 
sitivity to the names of function arguments by virtue of the same a-conversion 
rule. Alternatively, consider the task of evaluating functional programs. Using 
the notation F[f:=T] to depict the logically correct substitution of T for / in F, 
one of the rules relevant to this is the following: 

F[f:=(fixpt (f) F)] > V 
(fixpt (f) F) > V 

This rule can be encoded in the following AProlog clause: 

(eval (fix F) V) (eval (F (fix F)) V). 

The required substitution is, once again, realized via the /3-conversion rule. 



2.2 Structure Analysis using Higher-Order Unification 

Another useful property of the higher-order abstract syntax representation is 
that the unification operation over it provides for sophisticated forms of struc- 
ture analysis. This observation has been used previously by Huet and Lang in 
recognizing program properties [9]. Consider, for example, the term 

(fix Xf (abs Xm(abs An 

(eond (C m n) (T m n) ( app ( app f (El m n)) ( E2 m n)))))) 

in which the symbols C, T, El and E2 represent variables that may be instan- 
tiated to obtain terms that correspond to actual programs. Thus, the program 
term corresponding to faet is obtained from this term through the substitution 
of XmXn(eq m 0), XmXn n, XmXn(minus ml) and XmXn(times m n) for these 
respective variables. However, the logic places a restriction on what constitute 
correct instantiations: these cannot be carried out by terms that contain variables 
that get bound by the abstractions pertaining to /, m or n. Any dependencies in 
the subparts governed by C, T, El and E2 on the enclosing abstractions must, 

tation the user would, for instance, identify a new sort tm to correspond to program 
terms and fix and abs would be given the types (tm ^ tm) ^ tm. We elide these 
aspects for paucity of space, referring the reader to, e.g., [24] for such details. 




The Metalanguage Prolog and Its Implementation 



7 



therefore, be realized through the arguments of these variables. As a consequence 
of this requirement, the abstracted variable / must appear in exactly one place 
in any program term that matches with the ‘template’ being considered — as the 
head of the right arm of the conditional. It is easy to see that any program that 
corresponds to such a term must be tail recursive. The displayed term functions, 
in this sense, as a recognizer for tail recursive programs. 

Unfortunately, the template displayed is very limited in its applicability: any 
program it matches with must have a conditional as a body, must not contain 
nested conditionals, must have no recursive calls in the left branch of the con- 
ditional and must have a right branch that consists entirely of a recursive call. 
There are programs that violate all these requirements while still being tail re- 
cursive. A more important observation is that the limitation is inherent in any 
recognition scheme that uses templates alone: since conditionals can be arbitrar- 
ily nested, no finite collection of templates can be provided that recognize all 
tail recursive programs and only these. However, there is a recursive description 
of the relevant class of program terms that can be captured in a finite set of 
program clauses. In particular, consider the following, assuming that symbols 
beginning with uppercase letters denote instantiatable variables: 

1. A program is tail recursive if it contains no recursive calls and its represen- 
tation can be recognized by the term (fix Xf(abs Xm(abs Xn(H m n)))). 

2. A program that consists solely of a recursive call with possibly modified 
arguments is also tail-recursive and its representation must match with the 
term (fix Xf ( abs Xm ( abs An / app ( app f (El m n)) ( E2 m n))))). 

3. Finally, a program is tail-recursive if its body consists of a conditional in 
which there is no recursive call in the test and whose left and right branches 
themselves satisfy the requirements of tail-recursiveness. The representation 
of only such a program unifies with the term 

(fix Xf (abs Xm (abs Xn(cond (C m n) (T f m n) (E f m n))))) 
and in a way such that, under the instantiations determined for T and E, 
(fix Xf (abs Xm (abs Xn(T f m n)))) and (fix Xf (abs Xm (abs Xn(E f m n)))) 
represent tail-recursive programs. 

These observations provide a complete characterization of the criterion for tail 
recursiveness under consideration, and they translate immediately into the fol- 
lowing AProlog program: 

(tailrec (fix Xf (abs Xm(abs Xn(H m n))))). 

(tailrec (fix Xf (abs Xm(abs Xn(app (app f (El m n)) (E2 m n)))))). 

( tailrec (fix Xf (abs Xm (abs Xn(cond (C m n) (T f m n) (E f m n)))))) 

/ tailrec (fix Xf (abs Xm (abs Xn(T f m n))))), 

(tailrec (fix Xf (abs Xm(abs Xn(E f m n))))). 



Given a program term Prog, we can determine whether or not this represents a 
tail recursive program through a query of the form 
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?- tailrec Prog. 

Higher-order unification will play an important computational role in this recog- 
nition task. In particular, this operation will determine which of the terms in the 
heads of the clauses matches an incoming program term and, in the case of the 
last clause, will also aid in destructuring and subsequently constructing terms 
needed in the recursive calls. 



2.3 Recursion over Binding Structure 

The program for recognizing tail recursiveness just discussed has an obvious 
defect: it is applicable only to Unary recursive functions. A question to ask is 
if we can write a program to carry out such a recognition over arbitrary arity 
functions. Templates are not going to be very useful in this task since these must 
already anticipate the number of arguments for the function in their structure. 
A general solution to the problem must instead embody a systematic method 
for descending under the abstraction corresponding to each function argument; 
this method can then be applied as many times as is needed in any particular 
instance before conducting an analysis over the function body. 

The scoping primitives present in AProlog provide a means for realizing the 
necessary recursion over binding structure. The overall computation may, in fact, 
be structured as follows: The expression that has to be dealt with at the outset 
has the form (fix XfF). The objective in this case is to ensure that the free 
occurrences of / in F are all of a properly restricted kind. Such a check can be 
carried out by introducing a new constant c, annotating this constant so that 
it can be easily identified later, replacing all free occurrences of / in F with c 
and analyzing the resulting structure. A generic goal can be used to introduce 
the needed constant, its annotation can be realized by using an augment goal to 
make a special predicate true of this constant and substitution can be realized 
by application. At the next step, the expression encountered is of the form (abs 
XxB). The objective now is to analyze B, noting that a: may appear freely within 
this structure. Towards this end, a new constant may be temporarily added 
to the signature of the object language, the free occurrences of a: in B may 
be replaced with this constant and the resulting term may be further examined. 
These computations can, once again, be realized using a generic and an augment 
goal and function application. After a few repetitions of this step, the ‘body’ of 
the function would be reached. This is essentially a first-order structure the 
needed recursive analysis over which can be specified through Horn clauses. 

Assuming a definition for the predicate term that allows it to recognize terms 
corresponding to programs in the object language, the ideas just described trans- 
late into the following AProlog program: 

(tailrec (fix M)) V f ((recfn f) => (trfn (M f))). 

(trfn (abs R)) • - 'ix((term x) => (trfn (R x))). 

(trfn B) (trbody B). 

(trbody (cond CM N)) (term C), (trbody M), (trbody N). 
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(trhody M) : - (recfn M). 

(trhody (app M N)) (trhody M), (term N). 

The computation resulting from a use of the above clauses actually mimics the 
way the recognition task would have been structured had a conventional abstract 
syntax representation been used. In such a case, it would still be necessary to 
traverse the body of the function definition, checking the apparent uses of recur- 
sion. The advantage with the higher-order abstract syntax style of programming 
is that tedious bookkeeping steps — such as recording the function name and iden- 
tifying its free occurrences — receive a simple and logically precise treatment. The 
practical use of this approach depends, of course, on how efficiently the features 
supporting it can be realized. In the computation being considered, for exam- 
ple, several substitutions are performed over the function body by forming and 
contracting beta redexes. Carrying out these substitutions eagerly will result in 
several walks over the body of the function. Acceptable efficiency is dependent 
on mechanisms for delaying these substitutions so that they can performed in 
the same walk that analyzes the function body. 

The ideas that we have discussed in this section are quite general in their ap- 
plicability and they have, amongst other things, been used in encoding computa- 
tions that arise in theorem proving and manipulation of proofs [2,6], type check- 
ing [13] and the specification of programming language semantics [7]. Moreover, 
the features that support these ideas have also been widely exploited relative 
to the metalanguage Elf [30] and its successor Twelf [32]. Thus, the program- 
ming benefits of these features seem to be significant, making questions of their 
implementability important ones to address. 

3 Implementation Issues and Their Resolution 

The computational model underlying AProlog shares many features with the one 
used for Prolog: the goal to be solved at intermediate stages typically consists 
of a sequence of simpler ones, there may be choices in clauses to use in solv- 
ing atomic goals and unification provides the basis for matching an atomic goal 
with the head of a clause. Logic programming implementations embody mecha- 
nisms for dealing with all these aspects: sequential goal structure is realized with 
structure sharing using environment records and pointers to continuation code, 
a stack of choice point records is used to succinctly record alternative paths that 
may be followed on backtracking, the static information present in clause heads 
is used to compile significant parts of the unification computation and an under- 
standing of how data may become redundant is used to manage the allocation 
and reclamation of space. Much of this methodology is applicable to AProlog as 
well. However, there are differences in detail. Considering only the features of 
the language presently of interest, terms with a richer structure have to be rep- 
resented, a more sophisticated unification computation has to be realized and 
different signatures and programs may be relevant to the solution of distinct 
atomic goals. We discuss the new concerns that arise from these aspects below 
and outline approaches to their proper treatment within the broader framework. 




10 G. Nadathur 



3.1 Representation of Lambda Terms 

The usual requirement of a representation for lambda terms is that this support 
the operation of /3-reduction efficiently. Our special use of these as data structures 
raises additional concerns. Since it may be necessary to compare or destructure 
terms during execution, their intensions must be easy to access at run-time. 
At a logical level, two terms are considered to be equal if they differ only in 
the names of bound variables. The underlying representation must, therefore, 
support the rapid determination of a-convertibility. With respect to /3-reduction, 
it is desirable to be able to perform substitutions arising from this operation 
lazily and also to be able to combine several such substitutions so that they can 
be performed in the same walk over term structure. Functional programming 
language implementations embody a simple solution to this problem, and also 
to questions of a-convertibility, but one that gives up an ability that is important 
in our context: that of examining structure within abstraction contexts. 

Explicit substitution notations for lambda calculi that build on the de Bruijn 
method for eliminating bound variable names provide the conceptual basis for 
an adequate treatment of these representational questions. A popular version of 
such a notation is the Acr-calculus [1]. Our implementation of AProlog uses a 
different version called the suspension notation [21,28] that we believe is better 
suited to actual implementation. There are three categories of expressions in this 
notation that are referred to as terms, environments and environment terms and 
are given by the following syntax rules: 

{Term) ::= {Cons) \ {V ar) \ H^{Index) \ {{Term) {Term)) \ 

{\{Term)) \ [{T erm) , {N at) , {N at) , {Env)\ 

{Env) ::= nil \ {ETerm) :: {Env) 

{ETerm) ::= @{Nat) \ {{Term), {Nat)) 

In these rules, {Cons) and {V ar) represent constructors and instantiatable vari- 
ables, {Index) is the category of positive numbers and {Nat) is the category 
of natural numbers. Terms correspond to lambda terms. In keeping with the 
de Bruijn scheme, corresponds to a variable bound by the /th abstraction 
looking back from the occurrence. The expression \t,ol,nl,e\, referred to as a 
suspension, constitutes a new form of terms that encodes a term with a ‘sus- 
pended’ substitution: intuitively, this corresponds to the term t whose first ol 
variables have to be substituted for in the way determined by e and whose re- 
maining bound variables have to be renumbered to reflect the fact that t used 
to appear within ol abstractions but now appears within nl of them. Nominally, 
the elements of an environment either indicate the retention of an abstraction 
or are terms generated by a contraction. However, to encode the renumbering of 
indices needed during substitution, these are annotated by a relevant abstraction 
level. 

In addition to the syntactic expressions, the suspension notation includes a 
collection of rewrite rule schemata whose purpose is to simulate /3-reduction. 
These schemata are presented in Figure 1. Of these, the ones labelled {Ps) and 
{P'g) generate the substitutions corresponding to the /3-contraction rule on de 
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Ws) 


((Ati) <2) [i 


h,l, 0, (< 2 , 0) :: nil} 






iP's) 


{{\[ti,ol l,nl 1, @nl :: e]) < 2 ) - 


-t [ti. 


ol -I- 1, nl, (t 2 ,nl) :: e] 


(rl) 


|c, ol, nl, e] — )■ 


c, provided c is a constant 




(r2) 


lx, ol, nl, e] — )■ 


X, provided a: is a free variable. 


(r3) 


lifi, 0, nl, nil} 








(r4) 


1^1, ol, nl, @l 


:: e] #(n/ - 1). 






(r5) 


|#1, ol, nl, (t, /) :: e] |t, 0, nl - 1, 


nil}. 




(r6) 


lifi, ol, nl, et :: 


e] [#(* - l),o/ - 


1, nl. 


e], provided i > 1. 


(r7) 


|(ti t 2 ),ol,nl. 


e] (|ti,o/,n/,e] [i 


2 ,ol,nl,eJ). 


(r8) 


|(At),o/,n/, e] 


— )■ (A[t, ol l,nl 1 


, @nl 


:: e]). 



Fig. 1. Rule schemata for rewriting terms in the suspension notation 



Bruijn terms and the rules (rl)-(r8), referred to as the reading rules, serve to 
actually carry out these substitutions. The (/3^) schema has a special place in the 
calculus: it is the only one that makes possible the combination of substitutions 
arising from different /3-contractions. 

Unification and other comparison operations on terms require these to be 
first reduced to head-normal forms, i.e. to terms that have the structure 

(A...(A(...(/iti) ... U)--0 

where h, called the head of the term, is a constant, a de Bruijn index or an 
instantiatable variable. By exploiting the atomic nature of the rules in Figure 1, 
it is possible to describe a stack based procedure to realize reduction to such a 
form [20] and to embed this procedure and its use naturally into the structure of 
a logic programming implementation [23]. Furthermore, the rewriting order can 
be arranged so as to exploit the (/3^) schema to combine all the substitutions that 
need to be performed on a term into a single environment. Following this course 
has measurable advantages: in preliminary studies we have observed benefits in 
time from following this course as opposed to never using the (/3^) schema that 
range from 25% to 500% over the entire computation. 

We mention a few other salient issues relating to term representation. One of 
these relates to the internal encoding of applications. With reference to the head- 
normal form just displayed, there is a choice between representing the subterm 
under the abstractions as m iterations of applications as the curried presentation 
indicates or as one application with m arguments. There are practical advan- 
tages to the latter: access to the head, with which most structure examination 
begins, is immediate, the arguments, over which operations have to typically be 
iterated, are available as a vector and a close parallel to the WAM representation 
can be used for first-order terms. Our implementation of AProlog therefore uses 
this representation. In the realization of reduction, there is a choice between de- 
structive, graph-based, rewriting and a copying based one. The former seems to 
be conservative in both space and time and can be realized using a value trail- 
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ing mechanism within a WAM-like scheme. Finally, the terms in the suspension 
notation can be annotated in a way that indicates whether or not substitutions 
generated by contracting external /3-redexes can affect them. These annotations 
can permit reading steps to be carried out trivially in certain cases, leading also 
to a conservation of space and, possibly, a greater sharing in graph-based reduc- 
tion. Benefits such as these have been noted to be significant in practice [3], a 
fact confirmed also by our early studies using the Teyjus system. 

3.2 Supporting Higher-Order Unification 

The framework for organizing the unification computation relating to lambda 
terms is given by a procedure due to Huet [8].^ This procedure considers a 
set of pairs of terms of the same type with the objective of making the two 
terms in each pair identical; the set is called a disagreement set and each pair in 
it is a disagreement pair. Progress towards a solution is made by the repeated 
application of two different kinds of steps, both of which are based on the normal 
forms of the terms in a chosen disagreement pair. Referring to a term as flexible if 
the head of its head-normal form is an instantiatable variable and rigid otherwise, 
the first kind of step is one that simplifies a pair of rigid-rigid terms. In particular, 
if the normal forms of these terms are 

(A . . . (A(. . . {hi ti) ... tm)) ■■■) and (A . . . (A(. . . (/i 2 si) ... s „)) . . .), 

where the abstractions at the front have been arranged to be of equal length 
possibly by using the /^-conversion rule, the simplification step concludes that 
no unifiers exist if hi and /i 2 are distinct and replaces the pair with the pairs 
(ti,si ),. . . , {tmjSm) otherwise; we note that if hi and /i 2 are identical, typing 
constraints that we have left implicit up to this point dictate that n = m. The 
second kind of step deals with a flexible-rigid disagreement pair and it posits 
a finite set of substitutions for the variable at the head of the normal form 
of the flexible term that might be tried towards unifying the two terms. All 
substitutions must be tried for completeness, leading to a unification process 
that in general has a branching character. 

A useful special case of the application of the simplification step is the one 
where there are no abstractions at the front of the normal forms of the terms in 
the disagreement pair. In this situation, this step is similar to the term simpli- 
fication carried out in first-order unification. Further, when one of the terms is 
known ahead of time, the repeated application of the step to the pair and, subse- 
quently, to the pairs of subterms it produces can actually be compiled. Finally, if 
the instantiatable variables within terms appear not as the heads of applications 
but, rather, as leaves, the simplification process either indicates non-unifiability 
or produces a disagreement set in which at least one element or each pair is a 
variable. A generalization of the occurs-check procedure of first-order unification 

® Huet’s original procedure pertains to unifying the simply typed lambda terms that 
are used in AProlog. However, its structure has been utilized for unifying lambda 
terms with other typing regimens as well. 
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usually succeeds in the latter case in determining non-unifiability or in finding 
a most general unifier. The empirical study in [14] concludes that a large per- 
centage of the terms encountered in a AProlog-like language fit the ‘first-order’ 
description just considered. Unification of these terms can be treated efficiently 
and deterministically and it is important to reflect this into an implementation. 

There are other situations in which determinism in unification can be rec- 
ognized and exploited and many of these are embedded in the Teyjus system. 
However, a full treatment of higher-order unification has to eventually contend 
with branching and structures are needed to realize a depth-first, backtracking 
based search. The information that is needed for trying a different substitution 
for a flexible-rigid disagreement pair at a later time can be divided into two parts. 
One part corresponds to resetting program state to a point prior to making a 
choice in substitution; in a WAM-oriented model, this includes the values in 
the argument registers, the program pointer and the continuation pointer. The 
other part contains information for generating as yet untried substitutions and, 
if these are unsuccessful, for finding earlier backtracking possibilities. The com- 
putation model that is used in AProlog attempts to solve unification problems 
as completely as is possible before returning to goal simplification. In light of 
this, the state component of backtracking information will likely be common to 
more than one unification branch point. A representation and processing scheme 
can be designed that takes advantage of this situation to create only one record 
of the state information that is subsequently shared between all the relevant 
branch point records. 

The disagreement set representing a unification problem consists in certain 
situations of only flexible-flexible pairs. While solutions can be proposed for such 
problems, this cannot be done without significant redundancy. The most prudent 
course, therefore, is to treat such sets as constraints on the solution process that 
are to be resolved when they get more refined. An explicit representation of 
disagreement sets is necessary for realizing this strategy. The following factors 
affect the design of a satisfactory representation for this purpose: 

1. Disagreement sets change incrementally: they change when substitutions are 
made for variables, but these typically affect only a few pairs. For this reason, 
in representing a newly generated set it would be best if unchanged portions 
of the old set were reused. 

2. Backtracking may require a return to a disagreement set that was in exis- 
tence at some earlier computation point. For efficiency reasons, it should be 
possible to achieve such a reinstatement rapidly. 

Both requirements can be met by using a heap-based doubly linked list repre- 
sentation for the set. The removal of a pair from this list can be realized by mod- 
ifying pointers in the elements that appear before and after it. For backtracking 
purposes, it suffices to trail a pointer to the pair. To minimize bookkeeping, the 
addition of new pairs as a result of simplification must be done conservatively. 
Structures that may be used to support this are described in [23] . 
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3.3 Realizing Generic Goals 

The treatment of generic goals on the surface appears to be quite simple: when- 
ever such a goal is encountered, we simply generate a new constant, instantiate 
the goal with this and solve the resulting goal using the usual logic program- 
ming mechanisms. The problem, however, is that scope restrictions have also to 
be honored. To understand the specific issues, consider the situation in which the 
program consists of the single clause 'ix{p x x) and the desire is to solve the goal 
3y'iz{p y z). Using the usual treatment of existential goals in logic programming 
and the suggested one for generic goals, the given goal reduces to one of the 
form {p Y c) where c is a new constant and Y is an instantiatable variable. The 
attempt to solve this atomic goal must now take recourse to matching it with 
the program clause. If the usual notion of unification is used for this purpose, 
success will result with Y being bound to c. The problem is that this success is 
not legitimate since the binding for Y allows the new constant to escape out of 
its scope. Unification must therefore be constrained to prevent such solutions. 

The usual logical method for capturing restrictions arising out of quantifier 
scope is to instantiate universal quantifiers not with new constants but with 
Skolem functions of the existential quantifiers whose scope they appear within; 
occurs-check in unification then prevents illegal bindings of the sort just dis- 
cussed. There is a dual to Skolemization called raising [16] that applies to higher- 
order logics and this has, in fact, been used in some AProlog implementations. 
Unfortunately, the logic underlying AProlog is such that the needed Skolem func- 
tions (and their duals) cannot be statically determined [19,34], requiring lists of 
existential variables to be carried around and used in constructing the needed 
functions at runtime. Such a scheme is difficult to implement at a low level and 
certainly cannot be embedded well in an abstract machine. 

There is, however, an alternative way to view the instantiation restrictions 
[19] that does admit an elegant implementation. The central idea is to think of 
the term universe as being constructed in levels, each new level being determined 
by a generic goal that is dynamically encountered. Thus, suppose we are given 
the goal 3x\fy{p (/ x) a y) and that our signature initially consists of only the 
constructors / and a. The collection of terms at the first level consists of only 
those that can be built using / and a. Processing the existential quantifier in 
the given goal reduces it one of the form Vy(p (/ X) a y), where A" is a new 
instantiatable variable. Treating the generic goal now introduces a new constant 
c and transforms the goal to be solved into {p (/ X) a c). However, c and 
all the terms that contain it belong to the second level in the term universe. 
Furthermore, X can only be instantiated with terms belonging to the first level. 
A way to encode these constraints is to label constants and variables with level 
numbers. For a constant, this denotes the stage at which it enters the term 
universe. For a variable, the label determines the level by which a term must be 
in the universe for it to constitute a legal instantiation. 

An implementation of this scheme amounts to the following. A designated 
universe level is associated with each computation point and is maintained in a 
special register. A generic goal increments this register on entry and decrements 
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it on exit; special instructions can realize these effects in a compilation model. 
Constants and variables that result from generic and existential goals are labelled 
with the existing universe level at their point of creation. These labels are used 
whenever a variable needs to be bound during unification. At this time, an 
occurs-check process ensures that the binding is consummated only if no constant 
in the instantiation term has a higher label value than that of the variable. The 
same process also modifies the label on variables in the term to have a value no 
higher than that on the one being instantiated. This is needed to ensure that 
refinements to the instantiation term also respect the relevant constraints. 



3.4 Realizing Augment Goals 

Augment goals have the effect of parameterizing the solution of each goal in a 
sequence by a program. In a sequential implementation, this parameterization 
can be realized by modifying a central program as computation proceeds. Note 
that the program may have to change not only as a result of commencing or 
completing an augment goal, but also as a result of backtracking. From the 
perspective of efficient implementation, the following are important: Programs 
should have succinct descriptions that can be recorded easily in choice points. 
The addition of code upon entering an augment goal should be rapid as also 
the removal of code. Access to procedure definitions operative at any point in 
computation should be fast. Finally, compilation of predicate definitions that 
appear in augment goals should be possible. 

We outline here the scheme developed in [22] for realizing all these require- 
ments. The essence of this scheme is in viewing a program as a composite of 
compiled code and a layered access function to this code, with each augment 
goal causing a new layer to be added to an existing access function. Thus, con- 
sider a goal of the form {C\ A . . . A G„) D G where, for 1 < i < n, G, is a program 
clause with no free variables; this is not the most general situation that needs to 
be treated, and we will discuss the fully general case shortly. This goal requires 
the clauses Gi , . . . , G„ to be added to (the front of) the program before an at- 
tempt is made to solve G. Now, these clauses can be treated as an independent 
program fragment and compiled as such. Let us suppose that the clauses define 
the predicates pi, ... ,Pr- Compilation then produces a segment of code with r 
entry points, each indexed by the name of a predicate. In addition, we require 
compilation to generate a procedure that we call find-Code that performs the 
following function: given a predicate name, it returns the appropriate entry point 
in the code segment if the name is one of pi, . . . and fails otherwise. The 
execution of the augment goal results in a new access function that behaves as 
follows. Given a predicate name, find-Code is invoked with it. If this function 
succeeds, then the code location that it produces is the desired result. Otherwise 
the code location is determined by using the access function in existence earlier. 

* In the Teyjus implementation, findjoode amounts to pointers to a generic search 
function and a hash-table or a binary search tree. 
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The described method for enhancing program context is incomplete in one 
respect: rather than constituting completely new definitions, the clauses provided 
for pi, . . . may be adding to existing definitions for some of these predicates. 
Given this, compilation must produce code for each of these predicates that, 
instead of failing eventually, looks for code for the predicate using the access 
function existing earlier. Assuming that the last lookup occurs more than once, 
its effect may be precomputed. In particular, we may associate a vector of size 
r with the augment goal, the ith entry of which corresponds to the predicate pi. 
One of the actions to be performed on entering the augment goal is then that of 
using the existing access function with each of the predicates to place pointers 
to the relevant entry points into this vector. 

In a WAM-like implementation, the layered access function can be realized 
through a structure called an implication point record that is allocated on the 
local stack and that stores the following items: 

1. a pointer to an enclosing implication point record representing the previous 
access function, 

2. the findjcode procedure for the antecedent of the augment goal, 

3. a positive integer r indicating the number of predicates defined by the pro- 
gram clauses in the antecedent, and 

4. a vector of size r that indicates the next clause to try for each of the predi- 
cates defined in the antecedent of the augment goal. 

The program context at any stage is completely characterized by a pointer to an 
implication point record that may be stored in a specially designated program 
register. The goal {C\ A ... A C„) D G may be compiled into code of the form 

pushJmpl -point t 

{ Compiled code for G } 
pop -impl -point 

where push-impl -point and pop -impl -point are special instructions that realize 
the beginning and ending actions of an augment goal and t is the address of a 
statically created table that stores the findjcode function for this augment goal 
and also the numbers and names of the predicates defined. The push-impl -point 
instruction uses its table parameter and the program register to create a new im- 
plication point record in an entirely obvious way. The pop -impl -point instruction 
restores the old program context by using the pointer to the enclosing implication 
point record stored in the one currently pointed to by the program register. 

The scheme that we have discussed provides for a particularly simple real- 
ization of backtracking behavior as it concerns program context. Since this is 
given at any point by the contents of the program register, saving these contents 
in a choice point record at the time of its creation and retaining implication 
point records embedded under choice points ensures the availability of all the 
information that is needed for context switching. 

The structure we have assumed for augment goals up to this point embodies 
a simplification. In the most general case, a goal of the form {C\ A ... A G„) D G 
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may appear within the scope of universal quantifiers and the CjS may contain 
free, non-local, variables. Non-local variables can be treated by viewing a pro- 
gram clause as a combination of compiled code and a binding environment — in 
effect, as a closure — in the scheme described and leaving other details unchanged. 
Universal quantification over procedure names can lead to two different improve- 
ments. First, it may be possible to translate calls to such procedures from within 
G into a transfer of control to a fixed address rather than to one that is deter- 
mined dynamically by the procedure find-Code. Second, the definitions of such 
procedures within {C\ A ... A C„) cannot be extended, leading to a determinism 
that can be exploited in compiling these definitions and obviating entries for 
such procedures in the next clause vector stored in implication points. 



4 The Teyjus System 

The full AProlog language includes a typing regimen [26], facilities for conven- 
tional higher-order programming [24] and a modules notion for structuring large 
programs [17] in addition to the features considered in this paper. A curious as- 
pect about the types in the language is that they influence computations. They 
must, therefore, be present during execution and efficient methods are needed 
for constructing and carrying them around. In work not discussed here, we have 
addressed the implementation problems that arise from these other features [10, 
23,27] and have incorporated all our ideas into a virtual machine for AProlog. 

An implementation of AProlog based on our ideas envisages four software 
subsystems: a compiler, a loader, an emulator for the virtual machine and a user 
interface. The function of the compiler is to process any given module of AProlog 
code, to certify its internal consistency and to ensure that it satisfies a promise 
determined by an associated signature and, finally, to translate it into a byte 
code form consisting of a ‘header’ part relevant to realizing module interactions 
and a ‘body’ containing sequences of instructions that can be run on the virtual 
machine. The purpose of the loader is to read in byte code files for modules, to 
resolve names and absolute addresses using the information in the header parts 
of these files and to eventually produce a structure consisting of a block of code 
together with information for linking this code into a program context when 
needed. The emulator provides the capability of executing such code after it has 
been linked. Finally, the user interface allows for a flexibility in the compilation, 
loading and use of modules in an interactive session. 

The Teyjus system embodies all the above components and comprises about 
50,000 lines of C code. The functionality outlined above is realized in its entirety 
in a development environment. Also supported is the use of the compiler on the 
one hand and the loader and emulator on the other in standalone mode. The 
system architecture actually makes byte code files fully portable. Thus, AProlog 
modules can be distributed in byte code form, to be executed later using only the 
loader/emulator. The source code for the system and associated documentation 
is available from the URL http://teyjus.cs.umn.edu/. 
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5 Conclusion 

We have discussed the use and implementation of features of AProlog that pro- 
vide support for a higher-order approach to abstract syntax. We believe that 
there are many promising applications for these features, an observation that is 
accentuated by the extensive use that has been made recently of AProlog and the 
related language Twelf in prototyping experiments related to the proof-carrying 
code paradigm. The research we have described here also encompasses issues that 
are of broad interest to logic programming: matters related to typing, modular 
development of code and richer notions of equality between terms are important 
to other interpretations of this paradigm as well and the implementation ideas 
that we have developed should find applicability in these contexts. 

Considerable work remains to be done relative to the Teyjus system. Many 
design choices have been made with little empirical guidance in this first imple- 
mentation and it is important now to understand their practical implications and 
to refine them as needed. One category of choices concerns the representation of 
lambda terms. Explicit substitution notations provide only a framework for this 
and an actual realization has to address many additional issues such as sharing 
and optimality in reduction [11, 12], the extent of laziness and destructive ver- 
sus non-destructive realization. Another possibility not discussed at all here is 
that of lifting higher-order unification directly to such a notation [5] . Doing this 
simplifies the construction and application of substitutions but also necessitates 
bookkeeping steps that may be difficult to realize well in a virtual machine. The 
Teyjus system provides a means to study the pragmatic impact of such choices, 
a matter often downplayed in theoretical studies related to the lambda calculus. 
Along another direction, it appears important to improve on the module system 
and its realization so that it offers stronger support for separate compilation, 
permits dynamic linking and can be used as a basis for interfacing with foreign 
code. Another issue relates to garbage collection. The memory management built 
into a WAM-like implementation has its limitations and these are especially ex- 
posed by our use of the heap in carrying out /3-reductions in the Teyjus system. 
An auxiliary system therefore needs to be designed to reclaim disused space. 
A final question concerns the kind of support to provide for higher-order unifi- 
cation. The present realization of this operation uses a branching search but it 
may be possible to finesse this, using the ideas in [15] as is done in the Twelf 
system. Following this course has the additional advantage that the use of types 
can be limited to compile-time checking, leading to a significant simplification 
of the virtual machine structure. 

We are addressing these and other related questions in ongoing research. We 
also mention here that AProlog has received other implementations, one of these 
being the Prolog/Mali system [4,33]. Preliminary experiments with this system 
indicate a complementary behavior to that of Teyjus, with the former being more 
adept in the treatment of first-order computations and the latter with that of 
higher-order abstract syntax. This matter needs to be understood better and, 
where possible, the ideas in Prolog/Mali need to be exploited towards enhanced 
overall performance. 
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Abstract. Proof-Carrying Code (PCC) is a general mechanism for ver- 
ifying that a code fragment can be executed safely on a host system. 
The key technical detail that makes PCC simple yet very powerful is 
that the code fragment is required to be accompanied by a detailed and 
precise explanation of how it satisfies the safety policy. This leaves the 
code receiver with the simple task of verifying that the explanation is 
correct and that it matches the code in question. 

Previous implementations of PCC used safety explanations in the form 
of explicit formal proofs of code safety, thus gaining leverage from a sub- 
stantial amount of previous research in the area of proof representation 
and checking, but at the expense of poor scalability due to large proof 
sizes. In this paper we describe a series of changes that are necessary 
to achieve a truly scalable architecture for PCC. These include a new 
proof representation form along with a better integration of the various 
components of a PCC checker. We also present experimental results that 
show this architecture to be effective for checking the type safety of even 
very large programs expressed as machine code. 



1 Introduction 

More an more software systems are designed and build to be extensible and con- 
figurable dynamically. The proportion of extensions can range from a software 
upgrade, to a third-party add-on or component, to an applet. On another dimen- 
sion, the trust relationship with the producer of the extension code can range 
from completely trusted, to believed-not-malicious, to completely unknown and 
untrusted. In such a diverse environment there is a need for a general mechanism 
that can be used to allow even untrusted system extensions to be integrated into 
an existing software system without compromising the stability and security of 
the host system. 

Proof-Carrying Code (PCC) [NL96, Nec97] was designed to be a general 
mechanism that allows the receiver of code (referred to as the host) to check 
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quickly and easily that the code (referred to as the agent) has certain safety 
properties. The key technical detail that makes PCC very general yet very simple 
is a requirement that the agent producer cooperates with the host by attaching 
to the agent code an “explanation” of why the agent complies with the safety 
policy. Then all that the host has to do to ensure the safe execution of the 
agent is to dehne a framework in which the “explanation” must be conducted, 
along with a simple yet sufficiently strong mechanism for checking that (a) the 
explanation is acceptable (i.e., is within the established framework), that (b) the 
explanation pertains to the safety policy that the host wishes to enforce, and (c) 
that the explanation matches the actual code of the agent. 

Below is a list of the most important ways in which PCC improves over other 
existing techniques for enforcing safe execution of untrusted code: 

— PCC operates at load time before the agent code is installed in the host 
system. This is in contrast with techniques that enforce the safety policy by 
relying on extensive run-time checking or even interpretation. As a result 
PCC agents run at native-code speed, which can be ten times faster than 
interpreted agents (written for example using Java bytecode) or 30% faster 
than agents whose memory operations are checked at run time. 
Additionally, by doing the checking at load time it becomes possible to en- 
force certain safety policies that are hard or impossible to enforce at run 
time. For example, by examining the code of the agent and the associated 
“explanation” PCC can verify that a certain interrupt routine terminates 
within a given number of instructions executed or that a video frame ren- 
dering agent can keep up with a given frame rate. Run-time enforcement of 
timing properties of such fine granularity is hard. 

— PCC is small. PCC is simple and small because it has to do a relatively 
simple task. In particular, PCC does not have to discover on its own whether 
and why the agent meets the safety policy. 

— For the same reason, PCC can operate even on agents expressed in native- 
code form. And because PCC can verify the code after compilation and 
optimization, the checked code is ready to run without needing an additional 
interpreter or compiler on the host. This has serious software engineering 
advantages since it reduces the amount of security critical code and it is also 
a benefit when the host environment is too small to contain an interpreter 
or a compiler, such as is the case for many embedded software systems. 

— PCC is general. All PCC has to do is to verify safety explanations and to 
match them with the code and the safety policy. By standardizing a language 
for expressing the explanations and a formalism for expressing the safety 
policies it is possible to implement a single algorithm that can perform the 
required check, for any agent code, any valid explanation and a large class 
of safety policies. In this sense a single implementation of PCC can be used 
for checking a variety of safety policies. 

The combination of benefits that PCC offers is unique among the techniques 
for safe execution of untrusted code. Previously one had to sacrifice one or more 
of these benefits because it is impossible to achieve them all in a system that 
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examines just the agent code and has to discover on its own why the code is 
safe. 

The PCC infrastructure is designed to complement a cryptographic authenti- 
cation infrastructure. While cryptographic techniques such as digital signatures 
can be used by the host to verify external properties of the agent program, such 
as freshness and authenticity, or the author’s identity, the PCC infrastructure 
checks internal semantic properties of the code such as what the code does and 
what it does not do. This enables the host to prevent safety breaches due to 
either malicious intent (for agents originating from untrusted sources) or due to 
programming errors (for agents originating from trusted sources) . 

The description of PCC so far has been in abstract terms without referring 
to a particular form of safety explanations. There are a number of possible 
forms of explanations each with its own advantages and disadvantages. In any 
implementation the safety explanations must be precise and comprehensive, just 
like formal proofs. In fact, in the hrst realization of a PCC architecture [Nec98] 
the explanations were precisely formal proofs represented as terms in a variant 
of the dependently-typed A-calculus called the Edinburgh Logical Framework 
(LF) [HHP93]. The major advantage of this approach is that proof checking can 
be accomplished using a relatively simple and well understood LF type checker. 

The proof-based realization of PCC was very useful for gaining initial ex- 
perience with the PCC technique in various applications. However, when we 
attempted to try out PCC for medium and large examples it quickly became 
apparent that the size of the LF representation of proofs grows roughly quadrat- 
ically with the size of the program. (All experiments referred to in this paper 
are in the context of type-safety policies, for which the proof certihes that the 
machine code is well typed in a given, usually first-order, type system.) In an 
attempt to address this issue we hrst devised a simple extension of the LF type 
checker that enables it to reconstruct certain small but numerous fragments of 
proofs while type checking [NL98]. This variant of LF, which we call LF^ (for 
implicit LF), allows us to omit those fragments from the representation of proofs 
with the major beneht that proof sizes and the checking times are now growing 
linearly with the size of the program. This allows us to process examples up to 
several thousands of line of code with proof sizes averaging 2.5 to 5 times the 
size of the code. But even LFi-based proof representations are too large for the 
hundred-thousand line examples that we want to process. 

In this paper we describe a series of improvements to the PCC architecture 
that together allow us to process even the largest examples. These improvements 
range from major changes in the representation and checking of proofs to changes 
in the way different components of the PCC system communicate. We start in 
Section 2 with a description, in general terms, of the new proof representation 
technique that we use. Then, in Section 3 we demonstrate in the context of an 
example both the new proof representation technique and the way in which the 
various checker components communicate with each other. Although most of this 
paper focuses on the code-receiving end, we observed that for better scaling the 
code producer must also cooperate. We describe in Section 4 one way in which a 
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compiler that produces PCC agents can speed up the checking process. Finally, 
in Section 5 we discuss experimental evidence that substantiates the claim that 
this combination of techniques does indeed scale to very large examples. 

2 A Hint-Based Representation of Proofs 

One of the main impediments to scalability in the original proof-based realization 
of PCC is that proofs can be very large. Our solution to this problem is motivated 
by the observation that PCC proof checking is not able to exploit domain-specific 
knowledge in order to reduce the size of the proofs. For example, the PCC 
proofs of type safety are an order of magnitude larger than the size of the typing 
annotations that the Typed Assembly Language (TAL) system [MWCG99] uses. 
The overhead in TAL is smaller because TAL is less general than PCC and 
targets a specific type-safety policy, for a specific language and type system. The 
TAL type checker can be viewed as a proof checker specialized and optimized 
for a specific logic. 

What we need is a different PCC implementation strategy that allows the 
size of PCC proofs to adapt automatically to the complexity of the property 
being checked. As a result, we should not have to pay a proof-size price for the 
generality of PCC in those instances when we check relatively simple properties. 
There are several components to our new strategy. First is a slightly different 
view on how the proofs in PCC can assist the verification on the host side. We 
assume that the host uses a non-deterministic checker for the safety policy. Then, 
a proof can essentially be replaced by an oracle guiding the non-deterministic 
checker. Every time the checker must make a choice between N possible ways 
to proceed, it consults the next [log 2 N~\ bits from the oracle. There are several 
important points that this new view of PCC exposes: 

— The possibility of using non-determinism simplifies the design of the checker 
and enables the code receiver to use a simple checker even for checking a 
complex property. 

— This view of verification exposes a three-way tradeoff between the complexity 
of the safety policy, the complexity and “smartness” of the checker, and 
the oracle size. If the verification problem is highly directed, as is the case 
with typical type-checking problems, the number of non-deterministic choices 
is usually small, and thus the required oracles are small. If the checker is 
“smart” and can narrow down further the choices, the oracle becomes even 
smaller. At an extreme, the checker might explore by itself small portions of 
the search space and require guidance from the oracle only in those situations 
when the search would be either too costly or not guaranteed to terminate. 

— In the particular case of type-checking, even for assembly language, the 
checking problem is so directed that in many situations there is only one 
applicable choice, meaning that no hand-holding from the oracle is needed. 
This explains the large difference between the size of the typing derivation 
(i.e. the size of the actual proof) and the size of the oracles in our experi- 
ments. 




A Scalable Architecture for Proof-Carrying Code 25 




Fig. 1. The high-level structure of the PCC architecture. 



— This view of PCC makes direct use of the defining property of the complexity 
class NP. This suggests that one of the benefits of PCC is that it allows the 
checker to check the solutions of problems in NP in polynomial time (with 
help from the oracle). But PCC can also help with checking even of solutions 
for semi-decidable problems, provided the checker and the oracle negotiate 
before hand a limit on the number of inference steps to be carried during 
verification. 

— Since oracles are just streams of bits and no lookahead is necessary, they can 
be used in an online fashion, which is harder to do with syntactic represen- 
tations of proofs. This leads to a smaller memory footprint for the checker, 
which is important in certain applications of PCC for embedded devices. 



A high-level view of an oracle-based architecture for PCC is shown in Fig- 
ure 1. The untrusted code is first inspected by a verification condition gener- 
ator (VCGen) that checks simple syntactic conditions (e.g. that direct jumps 
are within the code boundary). Each time VCGen encounters an instruction 
whose execution could violate the safety policy, it asks the Checker module to 
verify that in the current context the instruction actually behaves safely. For 
this purpose, VCGen encodes the property to be checked as a simple symbolic 
formula. Our choice for the implementation of the Checker module is as a non- 
deterministic logic interpreter whose goals are the formulas produced by VCGen 
and whose logic program is an encoding of the host’s safety policy. The next 
section describes in more details these components in the context of a simple 
example. 
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bool foralKbool *data, int dlast) { 
int i ; 

for(i=dlast; i >= 0; i — ) 
if ( ! data[i]) return false; 
return true ; 

} 



Fig. 2. The C code for a function that computes the conjunction of all elements in an 
array of booleans. 



3 An Extended Example 

In this section we describe the operation of the PCC checking infrastructure 
in the context of verifying a simple type-safety policy for an agent written in 
a generic assembly language. Due to space limits and to keep the presentation 
concise we consider here only a trivial agent consisting of a function that com- 
putes the boolean value representing the conjunction of all elements in an array 
of booleans. The C source code for the function is shown in Figure 2. The inputs 
consist of a pointer to the start of an array of booleans along with the index 
of the last element. To simplify the presentation somewhat the array is scanned 
backwards. 

1 /* rd=data, n=dlast */ 

2 Vi = ri 

3 Lo: 

4 n = ge Vi, 0 

5 j false rt, Li 

6 n = add Vd, Vi 

7 rt = load t 

8 j false rt, L 2 

9 rt = sub rt , 1 

10 jump Lo 

11 Li: ret 1 

12 \ j 2 ' ret 0 



Fig. 3. The assembly language code for the function shown in Figure 2. 



In Figure 3 we show one possible compilation of the forall function into 
a generic assembly language. The resulting program uses four registers, and 
ri to hold respectively the start address and the index of the last element of 
the array, a register to hold the value of the local variable i and a temporary 
register r*. 
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3.1 The Safety Policy 

Before the code producer and the host can exchange agents they must agree on a 
safety policy. Setting up the safety policy is mostly the host’s responsibility. For 
our example, the safety policy is a variant of type safety and requires that all 
memory accesses be contained in a memory range whose starting value and last- 
element index are being passed by the host in the input argument registers 
and Ti . Furthermore, only boolean values may be written to that memory range 
and the agent may assume that the values read from that memory range are 
themselves boolean values. The safety policy further specihes that the function’s 
return value must be a boolean value. Finally, the safety policy specifies that 
only the values 0 and 1 are valid boolean values. 

It is obvious that this safety policy is tailored to our example and thus is not 
very general. To alleviate this problem we allow the host to define a language of 
types along with their meaning and the agent to customize the safety policy by 
declaring the type of the arguments that it expects and the type of the return 
value. This constitutes the interface of the agent and in our system is expressed 
as a pair of a function precondition and postcondition formulas constructed by 
the code producer using a number of type constructors defined by the host’s 
safety policy. 

In the case of our example the agent declares the following specification: 

Preforaii = Td- array(bool, n) 

Postforaii = res : bool 

which is a straightforward transcription of the function type. This specification 
uses the infix binary predicate constructor to denote that a certain register 
contains value of a certain type, along with two type constructors, array and 
bool. Somewhat unusual for a type, the array type constructor declares the 
index of the last element of the array along with the type of the array elements. 
In the postcondition, the name res refers to the result value. 

These predicate and type constructors are declared as part of the trusted 
safety policy along with inference rules (or typing rules) that specify how the 
constructors can be used. We show in Figure 4 the rules of inference that are 
necessary for our example. In order to understand these rules we preview briefly 
the operation of the VCGen. We do so here with only enough details to motivate 
the form of the rules. More details on VCGen follow in Section 3.3. 

When VCGen encounters a memory read at an address Ea, it asks the 
Checker module to verify that the predicate saferd(Fia) holds according to 
the trusted rules of inference. The hrst rule of inference from Figure 4 says that 
one instance in which a memory read is considered safe is when it falls within 
the boundaries of an array. The rule mem goes even further and says that the 
value read from an array has the same type as the declared array element type.^ 

^ Since the contents of memory does not change in onr example we can introdnce a 
constructor mem such that mem{E) denotes the contents of memory at address E. In 
general, a different mechanism must be used to keep track of the memory contents in 
the presence of memory writes. The reader is invited to consult [Nec98] for details. 
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A : array(r, L) / > 0 I < L 
saf erd(add(A, /)) 



rd 



A : array(T, L) I > 0 I < L A: array(T, L) />0 7<L 

- mem wr 



mem(add(A, /)) : T 



0 : bool 



boolO 



1 : bool 



saf ewr(add(j4, /), E) 
booll 



eqid 



7 < -E ge(7, 0) ge(E,0) 

leqid ^ ^ dec ^ geqO 



E = E E < E sub(7, 1) < E E > 0 

Fig. 4. The rules of inference that constitute the safety policy for our example. 



Similarly, the predicate safewr(Ea,E) is generated by VCGen to request a ver- 
ification that a memory write of value E at address Ea is safe. The third rule 
of inference in our safety policy can prove such a predicate if Ea falls inside an 
array and if E has the array element type. Notice that in all of these rule the 
function add has been used instead of the usual mathematical function “-h”. 
This is because we want to preserve the distinction between the mathematical 
functions and their approximate implementation in a processor. 

The rules boolO and booll specify the representation of booleans. The last 
row of inference rules in Figure 4 are a sample of the rules that encode the 
semantics of arithmetic and logic machine instructions. Consider for example 
the rule dec rule. Here ge and sub are the predicate constructors that encode 
the result of the machine instructions with the same name. VCGen uses such 
predicate constructors to encode the result of the corresponding instructions, 
leaving their interpretation to the safety policy. The rule dec says that the 
result of performing a machine subtraction of 1 from the value I is less or equal 
to some other value E if 7 itself is known to be less-or-equal to E and also 
if the test ge(7, 0) is successful. This rule deserves an explanation. If we could 
assume that the machine version of subtraction is identical in behavior to the 
standard subtraction operation then the rule would be sound even without the 
second hypothesis. However, the second hypothesis must be added to prevent 
the case when 7 is the smallest representable integer value and the sub operation 
underflows. (A weaker hypothesis would also work but this one is sufRcient for 
our example.) The rule geqO say that in comparisons with zero the meaning of 
the machine ge operation is the same as that of the mathematical greater-or- 
equal comparison. 

The rules of Figure 4 constitute a representative subset of a realistic safety 
policy. The safety policy used for the experiments discussed in Section 5 for the 
type system of the Java language consists of about 140 such inference rules. 
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3.2 The Role of Program Annotations 

The VCGen module attempts to execute the untrusted program symbolically in 
order to signal all potentially unsafe operations. To make this execution possible 
in hnite time and without the need for conservative approximations on the part of 
VCGen, we require that the program be annotated with invariant predicates. At 
least one such invariant must be specihed for each cycle in the program’s control- 
flow graph. To further simplify the work of VCGen each such invariant must also 
declare those registers that are live at the invariant point and are guaranteed to 
preserve their values between two consecutive times that the execution reaches 
the invariant point. We call these registers the invariant registers. 

For our example, at least one invariant must be specified for some point inside 
the loop that starts at label Lq. We place the following invariant at label Lg: 

Lo : INV = n < n REGS = {rd,r;} 

The invariant annotation says that whenever the execution reaches the label 
Lq the contents of register rt is less-or-equal to the contents of register n and 
also that in between two consecutive hits of the program point the register 
and ri are the only ones among the live registers that are guaranteed to preserve 
their values. 

A valid question at this point is who discovers this annotation and how. 
There are several possibilities. First, annotations can be inserted by hand by the 
programmer. This is the only alternative when the agent code is programmed in 
assembly language or when the programmer wants to hand-optimize the output 
of a compiler. It is true that this method does not scale well, but it is nevertheless 
a feature of PCC that the checker does not care whether the code is produced 
by a trusted compiler and will gladly accept code that was written or optimized 
by hand. 

Another possibility is that the annotations can be produced automatically 
by a certifying compiler. Such a compiler first inserts bounds checks for all array 
accesses. In the presence of these checks the invariant predicates must include 
only type declarations for those live registers that are not declared invariant. An 
exception are those registers that contain integers, for which no declaration is 
necessary or useful since the integer data type contains all representable values. 
In our example, the reader can verify that in the presence of bounds checks 
preceding the memory read the invariant predicate true is sufhcient. In general, 
the invariant predicates that are required in the absence of optimizations are 
very easy to generate by a compiler. 

An optimizing compiler might analyze the program and discover that the 
lower bound check is entailed by the loop termination test and the upper bound 
check is entailed by a loop invariant ‘Vi < ri’ . With this information the optimiz- 
ing compiler can eliminate the bounds checks but it must communicate through 
the invariant predicate what are the loop invariants that it discovered and used in 
optimization. This is the process by which the code and annotations of Figure 3 
could have been produced automatically. The reader can consult [Nec98] for the 
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detailed description of a certifying compiler for a safe subset of C and [CLN+00] 
for the description of a certifying compiler for Java. 

Finally, note that the invariant annotations are required but cannot be trusted 
to be correct as they originate from the same possibly untrusted source as the 
code itself. Nevertheless, VCGen can still use them safely, as described in the 
next section. 

3.3 The Verification Condition Generator 

The verification condition generator (VCGen) is implemented as a symbolic eval- 
uator for the program being checked. It scans the program in a forward direction 
and at each program point it maintains a symbolic value for each register in the 
program. These symbolic values are then used at certain program points (e.g. 
memory operations, function calls and returns) to formulate checking goals for 
the Checker module. To assist the checker in verifying these goals VCGen also 
records for each goal that is submitted to the Checker a number of assump- 
tions that the Checker is allowed to make. These assumptions are generated 
from the control-flow instructions (essentially informing the Checker about the 
location of the current program point) or from the program-supplied invariants. 
Figure 5 shows a summary of the sequence of actions performed by VCGen for 
our example. 

First, VCGen initializes the symbolic values of all four registers with fresh 
new symbolic values to denote unknown initial values in all registers. But the 
initial values of the registers and r; are constrained by the precondition. To 
account for this, VCGen takes the specified precondition and, without trying 
to interpret its meaning, substitutes in it the current symbolic values of the 
registers. The result is the symbolic predicate formula “do : array(bool, Iq)” that 
is added to a stack of assumptions. (These assumptions are shown underlined in 
Figure 5 and with an indentation level that corresponds to their position in the 
stack.) 

After these initial steps VCGen proceeds to consider each instruction in turn. 
The assignment instruction of line 2 is modeled as a assignment of symbolic val- 
ues. On line 3, VCGen notices that it hit an invariant. Since the invariant is not 
trusted VGGen asks the Checker to verify first that the invariant predicate holds 
at this point. To do this VCGen substitutes the current symbolic register val- 
ues in the invariant predicate and the resulting predicate < lo” is submitted 
to the Ghecker for verification. (Such verification goals are shown in Figure 5 
right-justified and boxed.) 

Then, VGGen simulates symbolically an arbitrary iteration through the loop. 
To achieve this VCGen generates fresh new symbolic values for all registers, ex- 
cept the invariant ones. Next VGGen adds to the assumption stack the predicate 
“*i < ^o” obtained from the invariant predicate after substitution of the new 
symbolic values for registers. 

When VCGen encounters a conditional branch it simulates both possible out- 
comes. First, the branch is assumed to be taken and a corresponding assumption 
is placed on the assumption stack. When that symbolic execution of that branch 
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1: Generate fresh values rd = do, n = lo, rt = io and rt = to 
1: Assume Precondition do : arrayCbool, lo) 



2: Set n = lo 



3: Invariant (first hit) 






1^0 


< lo 


3: Generate fresh values n = 


ii, rt = ti 








3: Assume invariant 


O 

VI 








4: Set n = ge(ii, 0) 










5: Branch 5 taken 


not (ge(d, 0)) 








11: Check postcondition 








booll 


5: Branch 5 not taken 


ge(d, 0) 








6: Set rt = add(do, *i) 










7: Check load 




1 saf erd(add(db , 


ET))] 


7: Set rt = mem(add(do, *i)) 










8: Branch 8 taken 


not (mem ( add ( do , 


ii))) 






10: Check postcondition 




E 




booll 



8: Branch 8 not-taken mem(add(do , ti)) 



9: Set n = sub(ii, 1) 

3: Invariant (second hit) 
4: Done 



subGi, 1) < ^0 > do - do , lo - lo 



Fig. 5. The sequence of actions taken by VCGen. We show on the left the program 
points and a brief description of each action. Some actions result in extending the 
stack of assumptions that the Checker is allowed to make. These assumptions are 
shown underlined and with an indentation level that encodes the position in the stack 
of each assumption. Thus an assumption at a given indentation level implicitly discards 
all previously occurring assumptions at the same or larger indentation level. Finally, 
we show right-justihed and boxed the checking goals submitted to the Checker. 
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terminates (e.g. when hitting a return instruction or an invariant for the sec- 
ond time), VCGen restores the state of the assumption stack and processes in a 
similar way the case when the branch is not taken. 

Consider for example the branch of line 5. In the case when the branch is 
taken, VCGen pushes the assumption “not (ge(ii, 0))” and continues the execu- 
tion from line 11. There a return instruction is encountered and VCGen asks the 
Checker to verify that the postcondition is verified. The precise verification goal 
is produced by substituting the actual symbolic return value (the literal 1 in this 
case) for the name res in the postcondition Postforaii- Once the Checker module 
verifies this goal, VCGen restores the symbolic values of registers and the state 
of the assumption stack to their states from before the branch was taken and 
then simulates the case when the branch is not taken. In this case, the memory 
read instruction is encountered and VCGen produces a saf erd predicate using 
the symbolic value of the registers to construct a symbolic representation of the 
address being read. 

The final notable item in Figure 5 is what happens when VCGen encounters 
the invariant for the second time. In this case VCGen instructs the Checker to 
verify that the invariant predicate still holds. At this point VCGen also asks the 
Ghecker to verify that the symbolic values of those registers that were declared 
invariant are equal to their symbolic values at the start of the arbitrary iteration 
thorough the loop. In our case, since the registers declared invariant were not 
assigned at all, their symbolic values before and after the iteration are not only 
equal but identical. 

This completes our simplified account of the operation of VGGen. For details 
on how VGGen deals with more complex issues such as function calls and mem- 
ory updates, the reader is invited to consult [Nec98]. Note that in the VGGen 
used in previous versions of PCC (such as that described in [Nec98]) the result 
of the verification condition generator is a single large predicate that encodes all 
of the goals (using conjunctions) and all of the assumptions (using implications). 
This means that the VGGen runs first to completion and produces this predicate 
which is then consumed by the Checker. This approach, while natural, turned 
out to be too wasteful. For large examples it became quite common for this 
monolithic predicate to require hundreds of megabytes for storage slowing down 
the checking process considerably. In some of the largest examples not even a 
virtual address space of IGb could hold the whole predicate. In the architec- 
ture that we propose here VCGen produces one small goal at a time and then 
passes the control to the Checker. Once a goal is validated by the Checker, it is 
discarded and the symbolic evaluation continues. This optimization might not 
seem interesting from a scientific point of view but it is illustrative of a number 
of purely engineering details that we had to address to make PCC scalable. 

3.4 The Checker Module 

The Checker module in the proposed architecture is simply a non-deterministic 
logic interpreter whose logic program consists of the safety policy rules of in- 
ference formulated as Horn clauses and whose goals are the formulas produced 
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by VCGen. For example, the rd inference rule of Figure 4 is expressed as the 
following clause written in Prolog notation: 

saf erd(add(A, /)) of(A, array(T, L), / > 0, I < L. 

There are two major differences between a traditional logic interpreter and 
our Checker. One is that in PCC the logic program is dynamic since assumptions 
(represented as logic facts) are added and retracted from the system as the sym- 
bolic execution follows different paths through the agent. However, this happens 
only in between two separate invocations of the Checker. The second and more 
important difference is that while a traditional interpreter selects clauses by try- 
ing them in order and backtracking on failure, the Checker is a non-deterministic 
logic interpreter meaning that it “guesses” the right clause to use at each step. 
This means that the Checker can avoid backtracking and it is thus signihcantly 
simpler and generally faster than a traditional interpreter. In essence the Check- 
ing contains a first-order unification engine and a simple control-flow mechanism 
that records and processes all the subgoals in a depth-first manner. The last el- 
ement of the picture is that the “guesses” that the Checker makes are actually 
specified as a sequence of clause names as part of the “explanation” of safety 
that accompanies the code. In this sense the proof is replaced by an oracle that 
guides the non-deterministic interpreter to success. 

As an example of how this works, consider the invocation of the Checker on 
the goal “saf erd(add(do, *i))”- For this invocation the active assumptions are: 

Ao = of (do, array(bool, Iq)) 

A\ = i\ < lo 

A2 = ge(H, 0) 

The fragment of oracle for this checking goal is the following sequence of 
clause names “rd, Aq, geqO, A2, Ai”. To verify the current goal the Checker 
obtains the name of the next clause to be used (rd) from the oracle and unifies 
its head with the current goal. This leads to the following subgoals, where T and 
L are not-yet-instantiated logic variables: 

of (do, array(T, L)) 

A > 0 

A < L 



To solve the first subgoal the Checker extracts the next clause name (Aq) 
from the oracle and unifies the subgoal with its head. The unification succeeds 
and it instantiates the logic variables T and L to bool and Iq respectively. Then 
the oracle guides the interpreter to use the rule geqO followed by assumption A2 
to validate the subgoal “zi > 0” and assumption Ai to validate the subgoal “il 
< lo" . The oracle for checking all of the goals pertaining to our example is: 



leqid, booll, rd, Aq, geqO, A2, Ai, boolO, dec, Ai, A2, eqid, eqid 
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3.5 An Optimized Checker 



So far we have not yet achieved a major reduction in the size of the “explanation” . 
Since the oracle contains mentions of every single proof rule its size is comparable 
with that of a proof. What we need now is to make the Checker “smarter” and ask 
it to narrow down the number of clauses that could possibly match the current 
goal, before consulting the oracle. If this number turns out to be zero then the 
Checker can reject the goal thus terminating the verification. In the fortunate 
case when the number of usable clauses is exactly one then the Checker can 
proceed with that clause without needing assistance from the oracle. And in the 
case when the number of usable clauses is larger than one the Checker needs 
only enough bits from the oracle to address among these usable clauses. 

Such an optimization is also useful for a traditional logic interpreter because 
it reduces the need for backtracking. By having phrased the checking problem 
as a logic interpretation problem we can simply use off-the-shelf logic program 
optimizations to reduce the amount of non-determinism and thus to reduce the 
size of the necessary oracle. 

Among the available logic program optimizations we selected automata- 
driven term indexing(ATI) [RRW95] because it has a relatively small complexity 
and good clause selectivity. The basic idea behind ATI is that the conclusions 
of all the active clauses are scanned and a decision tree is build from them. In- 
tuitively, the leaves of the decision tree are labeled with sets of clauses whose 
conclusions could match a goal whose structure is encoded by the path corre- 
sponding to the goal. This allows the quick computation of the set of clauses 
the could match a goal. For details on how the ATI technique is used in the 
implementation of the Checker the reader can consult [NROl]. 

In our example the ATI optimization works almost perfectly. For nearly all 
goals and subgoals it manages to infer that exactly one clause is usable. However, 
for three of the subgoals involving the predicate “<” the ATI technique confuses 
the correct clause (either Ai or dec) with the leqid rule. This is because ATI 
is not able to encode exactly in the decision tree conclusions involving duplicate 
logical variables. Thus the conclusion of the leqid rule is encoded as “Ai < A 2 ” , 
which explains why ATI would think that this conclusion matches all subgoals 
involving the < predicate. 

Even with this minor lack of precision the oracle for our example is reduced 
to just 3 bits. This constitutes a major saving. The original oracle consisted of 13 
clause names and since we never had more than 16 active clauses in our example, 
we could use 52 bits to encode the entire oracle. In practice we observe savings 
of more than 30 times over the uncompressed oracles. This is because it is not 
uncommon to have even 1000 clauses active at one point. This would happen 
in deeply nested portions of the code where there are many assumptions active. 
And the ATI technique is so selective that even in these cases it is able to filter 
out most of the clauses. 
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4 Compiler Support for Scalability 

So far we have described two techniques that proved essential for obtaining a 
scalable architecture for PCC: an oracle-based encoding of proofs and an inter- 
leaved execution of the VCGen and the Checker modules. Both of these tech- 
niques are implemented on the code-receiver end. But it would be incorrect to 
draw the conclusion that scalability can be achieved without cooperation from 
the code-producer end. 

To see how the code producer can and should help, recall that VCGen consid- 
ers both branches for each conditional and that symbolic execution stops when 
a return instruction is encountered or when an invariant is encountered for the 
second time. VCGen does verify that each cycle through the code has at least 
one invariant thus ensuring the termination of the symbolic evaluation. 

But consider a program without loops and with a long sequence of condi- 
tionals, such as the following: 

if(ci) Si else s'l; 

if(c„) s„ else s'„; 

return x 

VCGen considers each of the 2" paths through this function because it might 
actually be the case that each such path has a different reason (and proof) to 
be safe. In most cases (and in all cases involving type safety) the verihcation 
can be modularized by placing an invariant annotation after each conditional. 
Then VCGen will have to verify only 2n path fragments from one invariant to 
another. Thus the code producer should place more than the minimum necessary 
number of invariants. If it fails to do so then the number of verification goals, and 
consequently the size of the oracle and the duration of the verification process 
can quickly become very large. We have verihed in our experiments that this 
optimization is indeed very important for scalability. 



5 Experimental Results 

The experiments discussed in this section are in the context of a PGG system that 
checks Intel x86 binaries for compliance with the Java type-safety policy. The 
binaries are produced using a bytecode-to-native optimizing compiler [CLN+00]. 
This compiler is responsible for generating the invariant annotations. The oracle 
is produced on the code producer side in a manner similar to oracle checking. 
The VCGen is used as usual to produce a sequence of goals and assumptions. 
Each of these goals is submitted to a modified Ghecker engine that first uses 
the ATI engine to compute a small set of usable clauses and then tries all such 
clauses in order, using backtracking. Then this modihed Checker emits an oracle 
that encodes the sequence of clauses that led to success for each goal. 

We carried out experiments on a set of nearly 300 Java packages of varying 
sizes. Some of the larger ones are described in Figure 6. The running times 
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Program 


Description 


Source Size 
(LOG) 


Code Size 
(bytes) 


gnu-getopt 


Command-line parser 


1588 


12644 


Unpack 


Linear algebra routines 


1050 


17408 


jal 


SGI’s Java Algorithm Library 


3812 


27080 


nbody^ 


N-body simulation 


3700 


44064 


lexgen 


Lexical analyzer generator 


7656 


109196 


ocamF 


Ocaml byte code interpreter 


9400 


112060 


raja 


Raytracer 


8633 


126364 


kopi^ 


Java development tools 


71200 


760548 


hot java 


Web browser 


229853 


2747548 



Fig. 6. Description of our test cases, along with the size of the Java source code and 
the machine-code size, f indicates that source code was not available and the Java 
source size is estimated based on the size of the bytecode. 



Program 


LFi Size 
(bytes) 


LFi Checking Time 
(ms) 


Oracle Size 
(bytes) 


Logic Interpretation Time 
(ms) 


gnu-getopt 


49804 


82 


1936 


223 


Unpack 


65008 


117 


2360 


319 


jal 


53328 


84 


1698 


314 


nbody^ 


187026 


373 


7259 


814 


lexgen 


413538 


655 


15726 


1948 


ocamb 


415218 


641 


13607 


1837 


raja 


371276 


747 


11854 


2030 


kopi^ 


3380054 


5321 


96378 


14693 


hot java 


10813894 


19757 


354034 


53491 



Fig. 7. For each of the test cases, the size and time to check the LFi representation of 
proofs, the size of the oracles and the logic interpretation time using oracles. 



were averaged over a sufficient number of iterations of the checker on a 400MHz 
Pentium II machine with 128MB RAM. 

Based on the data shown in Figure 6 we computed, for each example, how 
much smaller are the oracles compared to LF^ proofs (shown in Figure 8), what 
percentage of the code size are the oracles (shown in Figure 9) and how much 
slower is the logic interpreter compared to the LF^ checker (shown in Figure 10). 
These figures also show the geometric means for the corresponding ratios over 
these examples. 

We observe that oracles are on average nearly 30 times smaller than LF^ 
proofs, and about 12% of the size of the machine code. While the binary represen- 
tation of oracles is straightforward, for LF^ it is more complicated. In particular, 
one has to decide how to represent various syntactic entities. For the purpose of 
computing the size of LF^ proofs, we streamline LF^ terms as 16-bit tokens, each 
containing tag and data bits. The data can be the deBruijn index [DeB72] for a 





Increase in Checking Time Size of Oracle Relative to Code Size Reduction in Proof Size 



A Scalable Architecture for Proof-Carrying Code 




Fig. 8. Ratio between LFi proof size and oracle size. 










cT 



Fig. 9. Ratio between oracle size and machine code. 




Fig. 10. Ratio between logic-interpretation time and LFi type-checking time. 
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variable, the index into the signature for constants, or the number of elements 
in an application or abstraction. 

We also compared the performance of our technique with that obtained by 
using a popular off-the-shelf compression tool, namely gzip. We do more than 3 
times better than gzip with maximum compression enabled, without incurring 
the decompression time or the addition of about 8000 lines of code to the server 
side of the PCC system. That is not to say that oracles could not benefit from 
further compression. There could be opportunities for Lempel-Ziv compression 
in oracles, in those situations when sequences of deduction rules are repeated. 
Instead, we are looking at the possibility of compressing these sequences at a 
semantic level, by discovering lemmas whose proof can be factored out. 

It is also interesting to note that logic interpretation is about 3 times slower 
than LFi type checking. This is due to the overhead of constructing the decision 
trees used by ATI. There are some simple optimizations that one can do to 
reduce the checking time. For example, the results shown here are obtained by 
using an ATI truncated to depth 3. This saves time for the maintenance of the 
ATI but also loses precision thus leading to larger oracles. If we don’t limit the 
size of the ATI we can save about 8% in the size of the oracles at the cost of 
increasing the checking time by 24%. 

One interesting observation is that while LF^ checking is faster than oracle 
checking, it also uses a lot more memory. While oracles can be consumed a 
few bits at a time, the LF^ syntactic representation of a proof must be entirely 
brought in memory for checking. While we have not measured precisely the 
memory usage we encountered examples whose oracles can be checked using less 
than 1Mbyte of memory while the checking of the corresponding LF^ terms could 
not be performed even with 1Gbyte of virtual memory. 



6 Conclusion 

We presented in this paper an architecture for Proof-Carrying Code where proofs 
are replaced by an oracle guiding a non-deterministic checker for a given safety 
policy. The luxury of using non-determinism in the checker allows a simple 
checker to enforce even complex safety policies. Since many safety policies are 
relatively simple, the amount of non-determinism is low and this leads to small 
oracles that are required for checking compliance with such policies. In this sense 
the proposed PCC architecture is able to adapt the cost of verihcation to the 
complexity of the safety policy. 

In designing this architecture we struggled to preserve a useful property of 
the previous implementation of PCC, namely that it can be easily conhgured 
to check different safety policies without changing the implementation. This has 
great software-engineering advantages and contributes to the trustworthiness 
of a PCC infrastructure since code that changes rarely is less likely to have 
bugs. To support this feature our choice for a non-deterministic checker is a 
non-deterministic logic interpreter that can be configured with the safety policy 
encoded as a logic program. 
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To achieve true scalability we had to solve several engineering problems, 
such as to design a low-cost interaction model between the various modules that 
compose the infrastructure. The code producer also must play an active role in 
ensuring that the verification process is quick. Through the combination of such 
techniques we have produced the first implementation of PCC that scales well to 
large programs at least in the context of a fairly simple type safety policy. What 
remains now to be seen is if Proof-Carrying Code can be practically applied to 
more complex safety policies. 
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Abstract. In this paper, we describe recent attempts to incorporate 
learning into logic programs as a step toward adaptive software that can 
learn from an environment. Although there are a variety of types of learn- 
ing, we focus on parameter learning of logic programs, one for statistical 
learning by the EM algorithm and the other for reinforcement learning 
by learning automatons. Both attempts are not full-fledged yet, but in 
the former case, thanks to the general framework and an efficient EM 
learning algorithm combined with a tabulated search, we have obtained 
very promising results that open up the prospect of modeling complex 
symbolic-statistical phenomena. 



1 Introduction 

We start by assuming that reproducing intelligence in a computer constitutes a 
great challenge to human intelligence in the 21st century. We on the other hand 
recall that the assumption held by AI researchers in the late seventies was such 
that it would be achieved by writing a huge program with a huge knowledge base 
(though no one knew how large they would be). The Rrst assumption is taken 
undebatable in this paper but the second one, once thought to be undebatable, 
raises a serious question in light of the fact that OS, software comprising tens 
of millions of codes, is far short of being intelligent. We must admit that the 
size of a program has little to do with its intelligence. It is also recognized that 
intelligence is something very complex and the most feasible way of building a 
very complex object comprised of tens of millions of components is to write a 
program. So we are trapped in a kind of dilemma that writing a huge program 
may not be a solution to building intelligence, but we seem to have no way other 
than that (at least at the moment). 

One way out is to note that programs can be smarter if they are born with the 
ability of learning, and it might be possible, instead of writing a huge complete 
program from the beginning, to let them learn how to behave more intelligently. 
Think of the following. Why is a program called a program? Because it specifies 
things to happen beforehand. And people have been taking it for granted that 
programs never change spontaneously regardless of how many times they are 
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used. Aside from the positive side, the negative side of this property is well- 
known; once an error occurs, the same error recurs indehnitely many times under 
the same condition. This stubbornness, “once built, no change,” of programs 
exhibits a striking contrast to human beings who grow with time and learn from 
mistakes. After learning, we expect that something changes for the better, but 
programs lack any means of learning as they are designed to be just symbolic 
constructs for dehning recursive functions, mathematically speaking. 

The lack of learning ability is a common feature of deductive symbolic sys- 
tems in general, and programs in particular, but there are well-established sym- 
bolic systems that have a close relationship to learning. For instance, there exist 
stochastic formal languages such as hidden Markov models (HMMs) [15].^ HMMs 
are used in many Reids from speech recognition to natural language processing 
to bioinformatics as a versatile modeling tool, and learning their parameters is 
a key step in their applications. Probabilistic context free grammars (PCFGs) 
[30,9],^ an extension of HMMs, have also statistical parameters learnable from 
linguistic data [1]. Turning to knowledge representation, we notice (discrete) 
Bayesian networks, a graphical representation of a finite joint distribution,^ 
are used to represent knowledge about uncertainty in the real world at propo- 
sitional level [13,2], and there is a standard way of statistically learning their 
parameters. Unfortunately, all these symbolic systems do not work as a program 
as they don’t have a means of expressing control and data structures. 

In the following,® we propose to integrate logic programs with parameter 
learning in hopes that they supply new building blocks for AI [16, 17,7,21,22]. 
Resulting systems have the ability of expressing programs and the ability of 
learning at the same time. They can compute as they are logic programs and 
can learn parameters as well. There exist a couple of problems with this ap- 
proach though. The most basic one is semantics. Notice that the basic principle 

^ A hidden Markov model is a stochastic finite antomaton in which a transition is 
made probabilistically and a probabilistically chosen alphabet is ontpnt on each 
transition. The state transition is snpposedly not observable from the ontside. 

^ A probabilistic context free grammar is a CFG with probabilities assigned to each 
prodnction rnle. If a nonterminal A has N prodnction rnles {A at \ 1 < i < IV}, 
probability pt is assigned to each rnle A ^ at {1 < i < N) in snch a way that 
— 1- The probability of a sentence s is the snm of probabilities of each 
(leftmost) derivation of s. The latter is the prodnct of probabilities of rnles nsed in 
the derivation. 

By a joint distribntion, we mean a joint probability density fnnction [3]. 

^ A Bayesian network is a graphical representation of a joint distribntion P{Xi = xi, 

. . . , Xn = xn) by a directed acyclic graph where each node is a random variable. A 
conditional probability table (CPT) representing P{Xt = Xt \ lit = Ui) (1 < * < N) 
is associated with each node Xt where lit represents the parent nodes (f < i < N) 
and Ut are their valnes. When Xt has no parent, i.e. a topmost node in the graph, 
the table is jnst a marginal distribntion P{Xt = Xi). The whole joint distribntion is 
given by P{Xt = x, | JT, = Ut). 

® The content of Section 2 and Section 3 is based on [22]. Related work is omitted dne 
to space limitations. 
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of logic is that “nothing is connected unless otherwise specihed by axioms” while 
the general rule of thumb in statistics is that “everything is connected unless 
otherwise specihed by independence assumptions.” This fundamental difference 
is carried over to semantics in such a way that logic has a compositional se- 
mantics, i.e. the meaning of A A B is a function of the meaning of A and that 
of B, but probability is not compositional, i.e. P(A A B) is not a function of 
P(A) and P(B). We are going to synthesize a new semantics by mixing these 
somewhat conhicting semantics in the next section for a class of parameterized 
logie programs, dehnite clause programs with a parameterized distribution over 
facts. 

The new semantics is called distribution semanties [16]. It considers a param- 
eterized logic program as dehning a joint distribution (of inhnite dimensions), 
and subsumes the standard least model semantics and the above mentioned sym- 
bolic systems, HMMs, PCFGs and Bayesian networks [17,22]. In the following, 
after having established distribution semantics for parameterized logic programs 
in Section 2, we apply it to symbolic-statistical modeling [17,18] in Section 3 
and show that three basic tasks, i.e. 

Task-1: computing probabilities 

Task-2: hnding out the most likely computation path 

Task-3: learning parameters from data 

are solved efhciently[7, 20-22]. Furthermore, in the case of PCFGs, we experimen- 
tally discovered that our learning algorithm called the graphieal EM algorithm 
outperforms the Inside-Outside algorithm [1], the standard parameter learning 
algorithm for PCFGs, by orders of magnitudes [22]. In Section 4, we investigate 
another direction of combining logic programming and learning by incorporat- 
ing reinforcement learning. Reinforcement learning is a method of online training 
by reward and penalty [5]. We show that logic programs incorporating learning 
automatons, simple reinforcement learning devices [12,14], can be trained to 
behave desirably for our purpose. 

The reader is supposed to be familiar with the basics of logic programming 
[8,4], probability theory [3], Bayesian networks [13,2] stochastic grammars [15, 
9], reinforcement learning [5] and learning automatons [12]. 

2 Semantic framework 

In this section, we dehne distribution semanties. Although it was already ex- 
plained in various places [16,17,21,22], we repeat the dehnition for the sake 
of self-containedness. First of all, our program is a dehnite clause program 
DB = TUi? in a hrst-order language £. with countably many constant symbols, 
function symbols and predicate symbols where T is a set of unit clauses and R, 
a set of non-unit clauses. To avoid mathematical complications, we pretend that 
DB consists of countably many ground clauses and no clause head in R appears 
in F . Our intention is that non-unit dehnite clauses represent eternal laws in the 
universe whereas unit clauses represent probabilistic facts which happen to be 
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true or happen to be false. So we introduce a probability measure Pp over the 
set of ground atoms in F and extend it to a probability measure Ppp over the 
set of Herbrand interpretations for C. 

Let fip be the set of Herbrand interpretations for the set of ground atoms 
in F and Rx an enumeration A\,A 2 , ... of ground atoms in L’.® A Herbrand 
interpretation has a one-to-one correspondence to an infinite series [x\, X 2 , ■ ■ ■) 
of Is and Os by stipulating that Xi = 1 (i = 1,2,...) (resp. = 0) if and only if 
Ai is true (resp. false). So Up is identified with the direct product 1}* 

of {0, l}s. The existence of a probability measure Pp over f^p is not self-evident 
but actually it is constructed freely from a collection of finite joint distributions 
P^\Ai = xi, . . . , A„ = x„) (n = 1,2, . . . , Xi Q {0, 1}, 1 < i < n) such that 

0 < = *1 , . . . , A„ = *„) < 1 

^ ^(^1 = Xl, . . . , An = *n) = 1 

P‘f'~''^\Ai =Xi,..., A„ + i = Xn + l) 

= P‘'p\Ai= Xi,. . ,,An= Xn) 

It is proved [3] that if P^p\-)s satisfy the three conditions of (1), there exists a 
(T-additive probability measure Pp such that for (n = 1, 2, . . . , G {0, 1}, 1 < 
i < n), 

Pp (Ai — X\, ... , An — ) — Pp (^1 — X\, ... , An — Xn) . 

pjp"\-)s are presentable as an infinite binary tree like Figure 1. In the tree, 
Pi, P 21 , P 22 , • • • (0 < Pi, P 21 , P 22 , • • • < 1) are free parameters, and the tree speci- 
fies Pp(Ai = I, A 2 = 0) = pi(l — P 21 ) and so on. 




Fig. 1. Making a collection of finite distribntions 



(n) 

Conversely, Figure 1 describes a general method of constructing Pp ^ but 
for practical reason, we assume that each probabilistic atom in F independently 
represents a probabilistic choice from a set of finitely many alternatives. So we 
introduce atoms of the form msw(i,n,r>) which simulates a multi-ary random 

® we assume that F contains conntably many ground atoms. 
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switch whose name is i and whose outcome is v on trial n as a generalization 
of primitive probabilistic events such as coin tossing and rolling a dice. We 
henceforth assume that Pp is specihed in the following way. 

1. F consists of probabilistic atoms msvi(,i ,n ,v) . The arguments i and n are 
arbitrary ground terms. We assume that a Rnite set Vi of ground terms is 
associated with each i, and v ^ Vi holds. 

2. Write Vi as {vi, V 2 , ■ ■ ■ , Vm} (m = \Vi\). Then, one of the ground atoms 
{msw(i,n,r>i), msw(i,n,r> 2 ), ..., msw(i,n,r>m)} becomes exclusively true 
(takes value 1) on each trial. With each i and (r> G Vi), a parameter 9i y G 
[0, 1] such that Xlugv = 1 is associated. 9i y is the probability of msw(i , ■ ,v) 
being true. 

3. For each ground terms i, i' , n, n' , v ^ Vi and v' G 14'/, random variable 
msw(i,n,r>) is independent of msw(i' , n' , r>') if n n' or i i' . 

Speaking more formally, we introduce a family of parameterized finite distribu- 
tion P(i,n) such that 

T’(i_„)(msw(i,n,t;i) = xi,. . . , msw(i , n , t;™) = Xm \ 9i^y^, . . ■,9i^y^) 

if J2T=i = 1 /2i 

\0 o.w. ^ ’ 

where m = |14|, x^ G {0,1} (1 < ^ < rn), and define Pp as the infinite- 
dimensional product measure 



='n^b.")' 

i,n 

Based on Pp, another probability measureT^jS over the set of Herbrand 
interpretations f^pp for £■ is constructed as an extension of Pp by making use of 
the least Herbrand model semantics of logic programs [16]. Think of a Herbrand 
interpretation p G i^p. It defines a set Fi, of true atoms in F, and hence defines 
the least Herbrand model Mppik') of F,^UR. Mppik') determines all truth values 
of ground atoms in £. A sampling p from Pp thus determines all truth values 
of ground atoms. In other words, every ground atom in £. becomes a random 
variable in this way. We formalize this idea. Enumerate all ground atoms m 
C and put it as Ai,^ 2 ,... Then introduce a collection of finite disrtibutions 
-Pz)B(dIi = Xi, ■ ■ ., An = Xn) (n = 1, 2, . . .) by 

A • • • A jjz G 12f I Mdb{v) ^ dl}' A • • • A } 

P^Dl{Ai = xi,...,An = Xn)’"= Pp{[Al^ h---AAl-]p) 

where = A if * = 1 and A^ = -lA if * = 0. Note that [A{^ A • • • A is 

Tf-measurable. Since P^pp (n = 1, 2, . . .) satisfies (1), there exists a probability 
measure PpB over f2pp, an extension of Pp, such that 

Pp B (Al — X\, ... , An — Xn) — Pp (Ai — X\, ... , An — Xn) 
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for every finite sequence of atoms Ai, . . . , A„ in F and for every binary vector 
[x\, . . . ,Xn) (xi G {0,1}, 1 < * < n). We consider Pdb(') as a joint distribu- 
tion of countably infinite dimensions and define the denotation of the program 
DB = F U R w.r.t. Pp as Ppp (distribution semantics). DB then becomes a 
random vector of inhnite dimensions having the distribution Ppp whose sample 
realization is a Herbrand interpretation for 

Distribution semantics subsumes the least Herbrand semantics in logic pro- 
gramming as a special case in which Pp places all probability mass on one 
interpretation, i.e. making a specihc set of ground atoms in F always true. On 
the contrary, it is also possible to dehne a uniform distribution over F (like the 
one over the unit interval [0, 1]) in which every Herbrand interpretation for F 
is equally probable. Since the cardinality of interpretations is just that of real 
numbers (fioB is isomorphic to Cantor set), each probability of an Mpb(v) is 
0 in this case. What we are interested in however is distributions between these 
extremes which better reflect our observations in the real world such as a corpus. 
The characteristics of distribution semantics are summarized as follows. 

— It is applicable to any parameterized logic programs. The underlying Rrst- 
order language is allowed to contain countably many symbols be they func- 
tions or predicates, and programs can be arbitrary. 

— Since it is based on the least model semantics, both sides of the iff defini- 
tion of a predicate^ p(a) ^ 3yi(x = ti A Wi) V • • • V A Wn) 

unconditionally coincide as a random variable for any ground instantiation 

p(t). 

— Unfold/fold transformation [25] preserves the denotation of parameterized 
logic programs. 

Owing to Pdb, we may regard every ground atom (and closed formula) as a 
random variable on f2pB- We apply our semantics in two directions, one for 
symbolic-statistical modeling described in Section 3, and the other for reinforce- 
ment learning described in Section 4. 

Before proceeding, we explain how to execute a parameterized logic pro- 
gram. Suppose DB = T U i? is a parameterized logic program such that F = 
{msw(i,n,r>)} has a distribution Pp = Yli n ,n) mentioned before, and also 
suppose a goal ^ G is given. We execute ^ G w.r.t. DB by a special SLD 
interpreter whose only difference from the usual one is an action taken for a goal 
msw(1 ,1, V) • When it is called with ground 1 = i and I = n, two cases occur.® 

— msw(i,n,V) is called for the first time. The interpreter chooses some ground 
term v from fj with probability 6i y , instantiates V to v and returns success- 
fully. 

^ Here x is a vector of new variables of length eqnal to the arity of p, p{t,) ^ W, 
(f < i < ra, 0 < n), an ennmeration of clanses abont p in DB, and each y,, a vector 
of variables occnrring in p(ti) ^ Wt. 

® If either I or N is non-gronnd, the execntion of ms¥(i,ra,V) is nnspecihed. 
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— msw(i,n,V) was called before, and the returned value was v. If V is a free 
variable, the interpreter instantiates V to v and returns successfully. If V is 
bound to some non-free variable v' , the interpreter tries to unify v' with v 
and and returns successfully if the unihcation is successful, or fails otherwise. 

Execution of this type is called sampling execution because it corresponds to 
sampling from Pu b ■ 

3 Statistical learning and parameterized logic programs 

3.1 Blood type example 

Parameterized logic programs dehne probabilities of ground atoms. Our aim 
here is to express our observations of symbolic-statistical phenomena such as 
observations of blood types by ground atoms, and write a parameterized logic 
program for them and adjust their parameters so that the distribution dehned 
by the program closely approximates to their empirical distribution. Let’s take 
ABO blood types. Possible types are ’A’, ’B’, ’0’ and ’AB’. We declaratively 
model by a parameterized logic program DBi = Fi U Ri in Figure 2 how 
these blood types are determined from inherited blood type genes {a,b,o}. 
Note that we employ Prolog conventions [?]. So strings beginning with a upper- 
case letter are variables. Quoted atoms are constants. The underscore is 
an anonymous variable. Apparently clauses in DBi are direct translation of ge- 



btype(’A’) (gtype(a,a) ; gtype(a,o) ; 
btype(’B’) (gtype(b,b) ; gtype(b,o) ; 
btype (’O’) : - gtype (o ,o) . 
btype(’AB’) (gtype(a,b) ; gtype(b,a)). 
gtype (X , Y) : - gene (f a,X) ,gene (mo , Y) . 
gene (P ,G) : - msw(gene ,P ,G) . 



gtype (o, a)) . 
gtype(o,b)) . 



Fi = {msw(gene ,P ,a), msw(gene ,P ,b), msw(gene ,P ,o)} 



Fig. 2. ABO blood type program DBi 



netic knowledge about blood types. btype( ’A’ ): - (gtype(a,a) ; gtype(a,o) 
; gtype (o, a)) for instance says one’s blood type is ’A’ if the inherited genes 
are (a, a), (a, o) or (o,a).® gene(fa,X) (resp. gene(mo,Y)) means one inherits 
a blood type gene X from the father (resp. Y from the mother). msw(gene,P,G) 
represents an event that G, gene, is probabilistically chosen to be inherited from 
P, a parent. 

^ The left gene (resp. the right gene) is snpposed to come from the father (resp. from 
the mother). 
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Ppi, a joint distribution over the set of {msw(gene , t, 3 ) | i G {fa, mo}, 3 G 
ja,b, o}}, is given as the product Pp-^ = 

_Pt(msw(gene , t, a) = *, msw(gene , t,b) = y, 

msw(gene,t,o) = z | 9a,0i,,9o) 9^9f9l 

Here t G {fa, mo) and one of {x, y, zj is 1 and the remaining two are 0. 9a is the 
probability of inheriting gene a from a parent and so on. When t ^ {fa, mo}, we 
put Pp,(-,-,-\,9a,9i,9o) = 0. 

Suppose we observed blood types. We represent such observations by atoms 
chosen from ohs(DBi ) = {btype ( ’ A ’ ) , btype ( ’ B ’ ) , btype ( ’ 0 ’ ) , btype ( ’ AB ’ ) } . 
Our concern then is to estimate hidden parameters 9 a, 9},, 9g from the observed 
atoms. First we reduce an observed atom to a disjunction of conjunction of 
msw atoms by unfolding [25]. Take btype(’A’) for instance. ^ btype(’A’) is 
unfolded by comp(Ri) [8,4] into 5i V ^2 V S 3 such that 

comp(Ri) h btype ( ’ A’ ) V ^2 V 53 

where 

51 = msw(gene,fa,a) A msw(gene ,mo , a) 

5 2 = msw(gene,fa,a) A msw(gene ,mo , o) 

5 3 = msw(gene,fa,o) A msw(gene ,mo , a) 

Each Si is called an explanation for btype(’A’) and { 51 , 52 , 5 s} is called the 
support set of btype ( ’ A’ Taking into account that 5i , S 2 and S 3 are mutually 
exclusive and msw atoms are independent, T£)Bj(btype( ’A’ ) is calculated as 

Pdb, (btype A’) \ 9a,9i,,9a) = Pp,(Si) + Pp, (S 2 ) + Pp, (S 3 ) 

= 9a p ‘29a9„ 

Hence, the values of 9a, 9i, and 9„ are determined as the maximizers of 9'a P‘^9a9„ 
(maximum likelihood (ML) estimation). When there are multiple observations, 
say T observations G\, , Gp, all we need to do is to maximize of the likelihood 

Y\a=i PoBiiGt I 9a, 9i, 9o), and this optimization problem is solvable by the EM 
algorithm [10], an iterative algorithm for ML estimation. We face a fundamental 
problem here however because the EM algorithm in statistics has been dehned 
only for numerically represented distributions and no EM algorithm is available 
for parameterized logic programs. So we have to derive a new one. Fortunately, 
thanks to the rigorous mathematical foundation of distribution semantics, it is 
straightforward to derive a (naive) EM algorithm for parameterized logic pro- 
grams [16, 6 , 22 ]. 

Given T observations Q = (Gi, . . . , Gp) of observable atoms and a parame- 
terized logic program DB that models the distribution of observable atoms, the 

An explanation S for a goal G w.r.t. a parameterized logic program DB = F U R is 
a minimal conjnnction S (C F) of msw atoms snch that S, R \~ G. The .support set 
iPdb(G) of G is the set of all explanations for G. 
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parameter set 6 which (locally) maximizes the likelihood PoBiiGt \ 8 ) is 

computed by an EM algorithm learn-naive{DB,G) below [16,6]. Here ipDB{Gt) 
(1 < t < T) is the support set of Gt and 8 is the set of parameters associated 
with msw atoms appearing in some ipDB{Gt). cgt,(5') is || n | msw(i,n,t;) G S'} |, 
the number of how many times an atom of the form msw(i,n,t;) appears in an 
explanation S. 



procedure learn-naive{DB , G) begin 

Initialize 8 with appropriate values and e with a small positive number ; 
\(o) ■— PoB(Gt I 8); % Compute the log-likelihood, 

repeat 

for each i (z I ,v (zVi do 
T 



T][i, t;] := ^ ■ 



1 



^ Pf(S\ ,(S); 



for each i (z I ,v (zVi do 

6i y := ■= — — I r; % Update the parameters. 

T.v-ev,v[hv'\ 

m := m + 1] 

y(m) := PoBiGt I 8) % Compute the log-likelihood again. 



until A(™) - < e 

end. 



% Terminate if converged. 



Our modeling process by a parameterized logic program DB of an observation 
G is summarized as follows (the case of multiple observations is analogous). 




3.2 OLDT and the graphical EM algorithm 

Symbolic-statistical modeling by parameterized logic programs has been for- 
mulated, but the real problem is whether it scales up or not. This is because 
for example the Rrst step in the modeling process includes the search of all 
explanations for G, and it can be prohibitively time consuming. If there are 
exponentially many explanations for G as is the case with HMMs, search by 
backtracking would take also exponential time. We circumvent this difhculty by 
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employing OLDT search [26]. OLDT is a complete refutation procedure for def- 
inite clause programs which reuses previously computed results saved in a table. 
Because it avoids computing the same goal twice, the search of all explanations 
by OLDT often can be done in polynomial time. In case of HMMs, search time 
is O(N^L) (N the number of states, L the length of an input string) and in case 
of PCFGs, it is O(N^L^) (N the number of non-terminals, L the length of an 
input sentence). 

The adoption of OLDT search yields a very favorable side effect on achieving 
Task-1, Task-2 and Task-3 in Section 1.^^ Since OLDT search shares sub- 
refutations, corresponding partial explanations are factored out, which makes 
it possible to represent the support set tposiG) compactly as a hierarchical 
graph called a support graph reflecting the sharing structure between explana- 
tions for G. Look at learn-naive{ D B , Q), especially the computation of PoBiGt \ 
0) and I The computation of PoBiGt \ 9) = 

J2seg>nB(Gt) I 9) takes time proportional to the number of explanations 

for Gi if it is implemented faithfully to this formula. We reorganize this compu- 
tation by introducing mstde probabiUties for logic programs as a generalization 
of the backward algorithm for HMMs [15] and the inside probabilities for PCFGs 
[1] in order to share subcomputations in J2seg>nB(Gt) \ 9). They are just a 

probability Pdb(f^ I 9) but recursively computed from the set of iff dehnitions 
of predicates and efhciently perform Task-1 in time proportional to the size of 
a support graph. 

The same optimization can be done for the computation of Pf(S \ 

9)(Ti^v(S) by introducing outside probabilities for logic programs as a generaliza- 
tion of the forward algorithm for HMMs [15] and the outside probabilities for 
PCFGs [1]. They represent the probability of “context” in which a specihc atom 
occurs. Inside probabilities and outside probabilities are recursively computed 
from a support graph and the computation takes time only proportional to the 
size of the graph. Thus a new EM algorithm called the graphieal EM algorithm 
incorporating inside probabilities and outside probabilities that works on sup- 
port graphs has been proposed in [7]. We omit the description of the graphical 
EM algorithm though (see [22] for the detailed description). When combined 
with OLDT search, it is shown [7,22] that 

OLDT search + (support graphs) + the graphical EM algorithm 

is as efhcient as specialized EM algorithms developed domain-dependently (the 
Baum- Welch algorithm for HMMs, the Inside-Outside algorithm for PCFGs and 
the one for singly connected Bayesian networks) complexity- wise. So Task-3 
is efficiently carried out in our framework. 

It is also easy to design an algorithm for Task- 2 that Rnds out the most likely 
explanation in time linear in the size of a support graph [20], which generalizes 

Detailed explanations are fonnd in [7,22]. 

This is a bit snrprising as the graphical EM algorithm is a single algorithm generally 
designed for dehnite danse programs (satisfying certain conditions [7, 22]) allowing 
recnrsion and inhnite domains. 
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the Viterbi algorithm for HMMs [15]. We therefore can say that the introduction 
of support graphs (constructed from OLDT search) and that of inside probabili- 
ties and outside probabilities for logic programs computed from a support graph 
efficiently solve the three tasks laid in Section 1. 

3.3 Learning experiments 

It is appropriate here to report some performance data about the graphical 
EM algorithm. We conducted learning experiments to compare the performance 
of the graphical EM algorithm with that of the Inside-Outside algorithm, the 
standard parameter learning algorithm for PCEGs, by using a real corpus and 
a PCEG developed for it. 

We used ATR corpus [28] containing 10,995 sentences whose minimum length, 
average length and maximum length are respectively 2, 9.97 and 49. The gram- 
mar, G^'pjp, is a hand crafted GEG comprising 860 rules (172 nonterminals and 
441 terminals) [27] developed for ATR corpus. G^'pjp, being not in Ghomsky 
normal form, was translated into GEG G^^fpjp in Chomsky normal form for the 
Inside-Outside algorithm to be applicable. ^ATR contains 2,105 rules (196 
nonterminals and 441 terminals). 

We created subgroups (I < L < 25) of sentences with length L and L + I 
by randomly choosing 100 sentences for each L from the corpus. Support graphs 
for S'iS w.r.t. G^'pjp and G^^fpjp were generated by Tomita (Generalized LR) 
parser by the way. After these preparations, for each S^, we compared time per 
iteration for the Inside-Outside algorithm to update the parameters of 
with that for the graphical EM algorithm to update the parameters of 
and The results are shown in Eigure 3. 

A vertical axis shows the required time. A horizontal axis is L, the length 
parameter of learned sentences. A curve labeled I-O in the left graph^® is drawn 
by the Inside-Outside algorithm. It is cubic as O(N^L^) predicts. The curves 
labeled gEM in the right graphs are drawn by the graphical EM algorithm. One 
with a comment “original” is for As seen from the graph, the graphical 

EM algorithm runs almost 850 times faster than the Inside-Outside algorithm 
at length 10 (the average sentence length in the ATR corpus is 9.97). The other 
one with “Chomsky NE” is the curve obtained by applying the graphical EM 
algorithm to The graphical EM algorithm still runs 720 times faster 

than the the Inside-Outside algorithm. Eurther more, a closer inspection reveals 
that update time by the graphical EM algorithm is almost linearly dependent 

The Inside-Outside algorithms requires a CFG to be in Chomsky normal form while 
the graphical EM algorithm accepts every form of production rules. 

We used a somewhat improved version of the Inside-Outside algorithm that avoids 
apparently redundant computations. For instance p ■ g(x) is immediately evalu- 
ated as 0 if p = 0. 

The right graph is an enlarged version of the left one. 

We would like to emphasize again that the graphical EM algorithm does not require 
a CFG in Chomsky normal form. This comparison is only made to measure time for 
updating parameters of a common PCEG. 
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Fig. 3. The Inside-Outside algorithm vs. the graphical EM algorithm 



on L, not on . The conclusion is that although the graphical EM algorithm 
has the same time complexity as the Inside-Outside algorithm, the difference in 
their performances is enormous when applied to real data, and the almost linear 
dependency of the graphical EM on the sentence length suggests that it can cope 
with the learning of a complex stochastic grammar applied to a bigger corpus 
with longer sentences. 

3.4 PRISM 

As an implementation of distribution semantics, a symbolic-statistical modeling 
language PRISM (URL = http : //sato-www . cs . titech. ac . jp/prism/) has 
been developed [16-18]. It is intended for modeling complex symbolic-statistical 
phenomena such as discourse interpretation in natural language processing, con- 
sumer behavior, gene inheritance interacting with complicated social rules [18]. 
As a programming language, it is an extension of Prolog with built-in predicates 
including msw predicate and other special predicates for manipulating msw atoms 
and their parameters. 

A PRISM program is comprised of three parts, one for directives, one for 
modeling and one for utilities. The directive part contains declarations telling the 
system what msw atoms will be used in the program. The modeling part is a non- 
unit dehnite clause program like DBi that dehnes the denotation of the program 
containing msw atoms. The last part, the utility part, is an arbitrary Prolog 
program which refers to predicates dehned in the modeling part. We can use there 
learn built-in predicate to carry out EM learning by learn-naive{DB,G) from 
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observed atoms. There are three modes of execution. The sampling execution 
corresponds to a random sampling drawn from the distribution dehned by the 
modeling part. The second one computes the probability of a given atom. The 
third one returns the support set for a given goal. These modes of execution 
are available through built-in predicates. Currently the implementation of the 
graphical EM algorithm and the simplihed OLDT search mechanism is underway. 



4 Reinforcement learning and parameterized logic 
programs 

4.1 Reinforcement learning 

We turn our attention here to on-line learning, i.e. data come one by one and 
learning is done each time. The idea is to use reinforcement learning [24,29] 
(see [5] for a survey) to reactively adjust parameters 9i k for msw(i,n,r>j,) (1 < 
k < N). Reinforcement learning is a model of learning good behavior by trial 
and error, by receiving reward and penalty from a random environment.^^ For 
instance, in Q-learning [29], one of the most popular reinforcement learning 
methods based on MDP (Markov Decision Process) [11], an agent is expected 
to learn, while randomly or systematically walking in the environment, a best 
action among several ones at each state to maximize its discounted or total 
expected reward. In this paper however, we adopt learning automatons [12,14] 
instead of MDP as an underlying theoretical framework because of their afhnity 
with parameterized logic programs as a learning device for msw atoms. 

A learning automaton (henceforth referred to as LA) is a reactive learning 
device working in a random environment. On each execution, it selects an action 
in proportion to choice probabilities assigned to each action, and adjust them in 
response to the gained reward so that proRtable actions are likely to be selected 
again. The point is that, while it just makes a random choice in the beginning, 
by repeatedly choosing an action and adjusting probabilities, it asymptotically 
converges to a stage where it only takes the most rewarding action (in average 
sense) [12,14]. 

We embed LAs in a parameterized logic program to automatically adjust 
parameters of msw atoms. Aside from the theoretical question about convergence 
of their collective behavior, the learning ability of LAs added to logic programs 
makes them reactive to the environment. We call such programs as reaetive 
logie programs. Reactive logic programs are intended to model an agent with 
rich background knowledge working in an uncertain world who learns from the 
environment how to behave optimally. 

By random, we mean the reward retnrned for taking an action is a random variable. 
In this paper, we assnme the environment is stationary, i.e. the distribntion of reward 
does not change with time. Also we leave ont penalty as a type of response for 
convenience. 

They reqnire neither the notion of state nor that of state change. 



18 




Parameterized Logic Programs where Computing Meets Learning 53 



4.2 Learning Antoniaton 

A learning automaton (LA) [12, 14]^® is a learning device applicable to a situation 
in which there are several possible actions with different probabilistic rewards, 
and we want to know the best one that maximizes the average reward. The most 
typical situation would be gambling. Imagine playing with a slot machine that 
has N levers (#-armed bandit). Pulling a lever gives us winnings if we are lucky. 
We want to know the best lever yielding the maximum average payoff while 
betting coins repeatedly. Which lever should we pull at nth time? 

One way to solve this problem is to use an LA. Suppose there are N possible 
actions ai, . . .,ajy. We associate a choice probability 0i(n) with each (1 < 
* < ^) so that ai is chosen with probability 0i(n) at time n. The distribution 
for actions at time n is expressed by a random vector 0(n) = ( 6 *i(n), . . . , Of^(n)) 
= !)• Suppose ai is chosen. By executing ai, we get a reward 7 from 
an environment®®, with which we update 9{n) by using Lr-j (Linear Reward- 
Inaction) scheme [12]®^ 

Oi{n -f 1) = Oi{n) + c„ 7 (l - Oi{n)) 

6 »j(n -p 1) = (1 - c„ 7 ) 6 »j(n) {j i) 

where c„ (0 < c„ < 1) is a learning rate at time n. The scheme says that if the 
reward 7 is non-zero, we will give more chance of selection to action ai. Since 7 
is a random variable, so are the 6i(n)s. Figure 4 illustrates an LA where edges 
denote actions and di is the average reward for action ai (1 < * < N). 




Fig. 4. A learning antomaton 



It is known that the Lr-j scheme can improve the average reward of the LA 
[12]. To see it, let 0(n) be a current distribution. M(n), the average reward at 
time n conditioned on 0(n), is derived as 

M{n) = E[j I e{n)] 

The type of LAs we nse is called a variable-strnctnre stochastic antomaton in [12]. 
We assnme 7 is normalized snch that 0 < 7 < 1. 

There are other learning schemes [12]. The Lr-i scheme is the simplest one. 
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N 

= '^ei{n)di (3) 

8 = 1 

where E[-] denotes expectation and di is the average reward for taking action 
(1 < i < N). M (n) is a random variable as a function of 6(n). E[M (n+1) | d(n)], 
the average reward at time n + 1 conditioned on 0(n), then comes out as 

N 

E[M{n + 1) I ^(n)] = I ^(^)] 

i = l 

= M{n) + - dj f9i{n)9j{n) (4) 

i,i 

> M{n) (5) 

By taking expectation of both sides in (5), we conclude 

E[M{n+l)]>E[M{n)] (6) 

i.e. the average reward is increasing at every time step. 

It is also important to note that {M (n)}n=i, 2 ,... forms a submartingale. Since 
E[M{n)\ < 1 holds for all n, {M(n)} has an a. s. (almost sure) convergence, which 
in turn implies, when the learning rate c„ is kept constant c, we see 9j{n) 0 

or 1 for every 9j{n) (1 < i < N). Regrettably, this does not necessarily mean 
that the probability 9i{n) corresponding to the maximum average reward di will 
converge to 1 with probability 1 after inhnite trials. However, it was proved that 
the probability of 9i(n) not converging to 1 is made arbitrarily small by setting 
c small enough [12]. Also, recently it also has been proved that if we decay the 
learning rate c„ like c„ = (a > &, 1 > & > 0), and if initial probabilities are 

positive, i.e. 9j(l) > 0 (1 < j < N) and di > dj for j ^ i, we have 9i(n) 1 

[14]. 

4.3 LA networks 

In reactive logic programming, parameters 9i k (1 < k < N) associated with 
msw(i,n,-) in a parameterized logic program are trained by an LA. The em- 
bedded LAs in the program as a whole constitute a tree, a dag (directed acyclic 
graph) or a more general graph structure. Unfortunately, unlike a single LA, not 
much has been known about the convergent behavior of the graph-structured 
LAs.^^ So we here introduce LA networks, the class of LAs organized as a dag 
and discuss their mathematical properties. Although we are aware that our re- 
active logic programming sometimes requires the use of a more general graph 

When there are multiple LAs connected with each other, the analysis becomes much 
harder. The reason is that for a given LA, other LAs are part of the environment 
and the average reward for a selected action becomes non-stationary, i.e. changes 
with time as the learning of the other LAs proceed, which prevents the derivation 
of formulas (5) which entails (6). 
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structures containing loops, we introduce LA networks because they are rela- 
tively expressive but yet analyzable. 




Fig. 5. A LA network 



Formally, a LA network is a connected dag (Figure 5) such that a node and its 
outgoing edges comprise an LA and there is the only one node with no incoming 
edges called the root LA. A node which has no descendent node is called a leaf 
LA. Each edge is labeled by an action and by the probability associated with it 
(see Figure 4). Actions are chosen sequentially from the root LA to a leaf LA in 
an obvious way and the reward is simultaneously given to each LA on the path 
from the root to the leaf to update choice probabilities. 

Let 0(n) be probabilities for all edges in the graph at time n, and M(n) 
the average reward at time n conditioned on 6(n). When the shape of the LA 
network is a tree, we can prove (6) w.r.t. the root LA by setting learning rates 
differently for each LA and for each trial (hierarchical systems [12]). On the 
other hand, the need of computing different learning rates is computationally 
disadvantageous compared to using a common constant learning rate, for which 
case we can still prove (5) (and hence (6)) under the condition that the reward 
is binary i.e. {0,1} (proof omitted). 

For LA networks which are not trees, we do not know at the moment if (5) 
holds w.r.t. the root LA for a constant learning rate. However, we proved in [19] 
that (5), the increase of the average reward, holds for arbitrary LA networks 
as long as a common learning rate with large enough a is used by all LAs 
at time n. That is, with this decaying learning rate, an LA network gains more 
reward on average every time the program is executed. What is disappointing 
about it is that it gives too slow convergence, experimentally. So we decided 
instead to use a constant learning rate set by a user. 
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4.4 LA library 

We built a library called LA library so that various built-in predicates are avail- 
able to manipulate LAs in a parameterized logic program. We here explain some 
of them. First new_choice(i,/ist) creates msw atoms {msw(i,t ,r>) | (r> G list)} 
with an LA attached to them with equal values for r>s. We use fresh t every on 
every execution of such msw atom. new_choice(sanfrancisco, [neworleans, 
Chicago]) for instance sets up a new LA named sanfrancisco that outputs 
equiprobably neworleans or Chicago, list is a list containing arbitrary terms 
but i must be a ground term. choice(i,V) executes an LA named i with a 
current distribution and the output is returned in V. reinforce_choice(c,/ist) 
adjusts according to the L_r_/ learning scheme choice probabilities in all LAs 
contained in list using the base line cost c (see Section 4.5). 

4.5 Reinforcement condition 

It must be emphasized that we are a tackling optimization problem. We use a 
reactive logic program expecting that by repeatedly running it, the parameters 
of LAs are automatically adjusted, and the most rewarding choice sequence will 
eventually gain the highest execution probability. In view of this, we should not 
apply reinf orce_choice/2 unconditionally every time computation is done, 
because we are not seeking for a correct answer but for a better answer that 
corresponds to a more rewarding choice sequence and there is no reason for 
giving out a reward to whatever answer is computed. 

We try to obtain a better answer by comparing a new one and the old ones. 
Suppose we run a program and the computed answer is judged better than 
the old ones. We reinforce every LA involved in the computation by invoking 
reinf orce_choice/2. The criterion for invocation is called a reinforcement con- 
dition. We can conceive of several reinforcement conditions depending on the 
type of problem, but in this paper, we use the following heuristic condition. 

where C is the cost of the computed answer, Cf the least cost achieved so far 
and Ca the average cost in the past M trials [M = 50 is used in this paper). 

4.6 Going to the East 

Now we present a very simple reactive logic program for a stochastic optimization 
problem. The problem is to Rnd a route in Figure 6 from San Francisco to New 
York but a traveling cost between adjacent cities (cost attached to edges in 
Figure 6) is supposed to vary randomly for various reasons on each trial. The 
task is to Rnd a route giving the least average cost. 

We Rrst deRne travel/2 predicate to compute the route and cost of traveling 
from the current city (low) to New York. 

Note that the condition is stated in terms of cost, so the lesser, the better. 
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SanFrancisco 



Chicago 




Fig. 6. Going to the East 



"/, Destination = Hew York 
travel (newyork , 0 , [newyork] ) . 
travel (How, Cost, [How I Route] ) 
choice (How, Next) , 
travel (Next, Cl, Route) , 
link_cost (How, Next, C2) , 

Cost is Cl + C2. 

link_cost/2 returns the traveling cost of adjacent two cities. It consists of a basic 
cost plus a random increment (uniform distribution, max 20%) determined by 

randomj£loat/2. 

link_cost(IFow, Next, Cost) 
cost (How, Next, Cl) , 
random_float(0.2,C2) , 

Cost is Cl * (1+C2). 

A table of basic cost is given by unit clauses (numbers are artificial). 

cost (sanf rancisco , neworleans, 10). 
cost (sanf rancisco , Chicago, 15). 
cost (sanf rancisco , stlouis, 12). 

cost (stlouis , newyork, 15). 
cost (atlanta, newyork, 18). 

After 10,000 trials of ?- travel(sanfrancisco, _,Route) with a learning 
rate 0.01 and the reinforcement condition previously stated, we obtained the 
following route. As can be seen, the recommended route (San Francisco, Hew 
Orleans, St. Louis, Hew York) gives the least average cost. How learning 
converges is depicted in Figure 8. It plotted the average cost in the past 50 
trials. We see that the average cost decreases rapidly in the initial 1,000 trials 
and then slowly. Theoretically speaking however, there is no guarantee of the 
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Fig. 7. A route to New York 



decreasing average cost when the learning rate is kept constant in an LA network 
with loops, but taking into account the fact that the average cost decreases with 
a decaying learning rate (Section 4.3), we may reasonably expect it happens as 
well provided the learning rate is kept sufficiently small. 




Fig. 8. Learning curve 



5 Conclusion 

We have presented attempts to make programs more adaptive by adding learning 
ability. In order to unify computing and learning at semantic level, distribution 
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semantics is introduced for parameterized logic programs that contain probabilis- 
tic facts with a parameterized distribution. The new semantics is a generalization 
of the least model semantics for dehnite clause programs to possible world se- 
mantics with a distribution. We then apply the semantics to statistical modeling 
in Section 3 and to reactive programming in Section 4. It is shown that efhcient 
symbolic-statistical modeling is made possible by the graphical EM algorithm 
working on a new data structure called support graphs. The learning experiments 
have shown that the graphical EM algorithm combined with OLDT search is not 
only as competitive as existing specialized EM algorithms complexity- wise, but 
in the case of PCEGs, runs 850 times faster than the Inside-Outside algorithm, a 
rather pleasant surprise. We also applied distribution semantics to reinforcement 
learning of parameterized logic programs by learning automatons, and showed a 
simple reactive programming example applied to a stochastic search problem. 
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Abstract. We formally prove the stackability and linearity of excep- 
tion handlers with ML-style semantics using a novel proof technique 
via an ordered logical framework (OLF). We first transform exceptions 
into continuation-passing-style (CPS) terms and formalize the exception 
properties as a judgement on the CPS terms. Then, rather than directly 
proving that the properties hold for terms, we prove our theorem for the 
representations of the CPS terms and transform in OLF. We rely upon 
the correctness of our representations to transfer the results back to the 
actual CPS terms and transform. 

Our work can be seen as two-fold: we present a theoretical justification 
of using the stack mechanism to implement exceptions of ML-like seman- 
tics; and we demonstrate the value of an ordered logical framework as a 
conceptual tool in the theoretical study of programming languages. 



1 This Work 

We formally prove a folklore property of exceptions of ML-like semantics: excep- 
tion handlers are used at most once (linearity) in a stack-like-manner (stackabil- 
ity) (i.e., installing an exception handler and handling an exception respectively 
amounts to “push” and “pop.”). Furthermore we show that the ordering proper- 
ties investigated in [DDP99,DP95] for results of the conventional continuation- 
passing-style (CPS) transformation [DF92,Plo75,Ste78] — stackability of both 
continuation identifiers and continuation parameters — also hold for results of 
an extended CPS transform[KYD98,App97] which replaces exception-raise and 
-handle expressions by function (continuation) calls and constructions in higher- 
order programs. 

We prove the two properties as follows: 
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1. In order to expose the semantics of exceptions in the program text, we encode 
exceptions in source programs with continuations by using the extended CPS 
transformation. 

2. We then formalize the properties of interest as a judgement on CPS terms. 

3. We then prove that all terms resulting from the transformation satisfy our 
judgement. 

We carry out the main portion of our proof (pt. 3 above) in a novel fashion — 
via an ordered logical framework (OLF) [PPOO], a new formalism which is par- 
ticularly well-suited for our purpose. Rather than directly proving that the prop- 
erties hold for terms (which would require a rather tedious logical-relations style 
argument [DDP99]), we directly prove our theorem for representations of the 
CPS terms and transform in OLF. By working in OLF we can take advantage 
of known properties of OLF terms (e.g. substitution properties) which simplify 
our task. We then rely upon the correctness of our representations to transfer 
the results back to the actual CPS terms and transformation. 

Our work can be seen as a theoretical justification of existing compilers that 
use the stack mechanism to implement exceptions. Our work also demonstrates 
the value of a (ordered) logical framework as a conceptual tool in the theoretical 
study of programming languages. We believe that working inside OLF greatly 
simplifies our proof. Of course such simplification comes at the cost of gaining 
familiarity with OLF. However, we feel the trade-off is advantageous. Logical 
frameworks have generally proven themselves to be useful tools for studying 
programming languages [Pfe96]; and we believe OLF, though still a new formal- 
ism, will likewise prove itself useful. 

1.1 Overview 

Section 2 introduces the ordered logical framework in which we will represent 
our terms and transform. In section 3.2 we define direct-style terms with ex- 
ception raise and handle expressions, CPS terms, and the CPS transformation 
for encoding exception-raise and -handle expressions by continuations. We also 
define judgements on CPS terms for stackability (and linearity) of the exception 
handling mechanism. In section 4 we give OLF representations for direct-style 
terms and for CPS terms satisfying the stackability judgements. In section 5 we 
show the representation of the CPS transformation. This representation takes 
represented direct-style terms to represented CPS terms. The correctness of this 
representation completes our proof since represented CPS terms correspond to 
actual CPS terms satisfying the stackability judgements. Finally, we give a con- 
clusion with some related and future work in section 7. 

2 Ordered Logical Framework 

OLF is a logical framework in the tradition of LF [HHP93] and its linear exten- 
sion LLF [CP99]. Thus OLF is essentially a dependent type theory^ for which 

^ Types can depend upon terms. 
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type checking is decidable and canonical forms exist. Since OLF has come un- 
der study quite recently, the remainder of this section provides the necessary 
background information to follow our proof. 

OLF should be thought of as ordered linear types [PP99a] extended with 
dependent types. Thus, we will first review ordered linear logic, the logic corre- 
sponding to ordered linear types. 



2.1 Ordered Linear Logic 

Ordered linear logic (OLL) is a conservative extension of intuitionistic linear 
logic with ordered hypotheses. We begin with a review of the fragment of OLL 



which we will use. For a description of the full system see [PP99b,PP99a] 


Types A ::= a 


atomic types 


1 To — )■ Ti 


intuitionistic implication 


1 To -» Ti 


ordered right implication 


1 To & Ti 


additive conjunction 


1 T 


additive truth 


Objects M ::= c 


constants 


\ x \ z 


variables 



I \x'.A. M I Mo Ml intuitionistic functions {A — )• B) 

I }^z:A. M I Mo^Mi right ordered functions {A -» B) 

I (M , iV) I 7Ti M I 7T2 M additive pairs { A & B) 

I 0 additive unit (T) 

We build typing rules for OLL objects from the following judgement 

r^fih M ■. A 

where T is a list of unrestricted hypotheses, f2 is a list of ordered hypotheses, 
and a signature containing constant declarations is left implicit. The inference 
rules will be structured to allow copying, discarding, and exchanging of unre- 
stricted hypotheses. However, ordered hypotheses will not enjoy those structural 
properties — they must be used exactly once in their relative order. 

Here are the rules for unrestricted functions. 

{r,x-.A)-, n\- M : B 

ivar — )•/ 

{ri,x:A,r 2 )-,- X : A r-,n\- \x:A. M : A^ B 

r-,n\- M : A^B r--\- N : A 

-^E 

r-,n\- MN : B 

Note that the ordered context in the minor premise of must be empty. 
This ensures that unrestricted functions, which may use their argument arbi- 
trarily, may not be applied to ordered arguments, which must be used exactly 



once. 
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The rules for ordered functions follow. 

T; {Q,z:A) M : B 

ovar ^ 

r-z:A\-z:A r- Q \- \ z:A. M : A B 

r-,ni \- M : A^ B r-,Q 2 \-N:A 
»E 

r- (f2i,f?2) I- N : B 



Note that the argument to an ordered function may only depend upon or- 
dered hypotheses to the right of those use by the body of the function — the order 
of the hypotheses constrains their use by ordered functions. 

Finally we give the rules for pairs and unit. 



r-.Q'r M ■. A r-.Q'r N -.B 

&/ 

T; f? h (M , TV) : T & B 



T/ 

P; f? h 0 : T 



r-.Q'r M ■. Ak,B 

&£i 

P; f? h 7Ti M : T 



P; f? h M : T & B 

&£2 

P; f? h 7T2 M : B 



The reduction rules for OLL objects are simply /3-reduction for both kinds 
of functions. The appropriate notion of equality of objects also includes re- 
conversion so that every well-typed object has an equivalent canonical form. 
Our calculus enjoys subject reduction, as proved in [PP99a]. 

Theorem 1 (Subject Reduction). 

and r-,f}h M ■. A then r-,f}h M' ■. A. 

Proof: For each reduction, we apply inversion to the given typing derivation and 
then use a substitution lemma to obtain the typing derivation for the conclusion. 
□ 



Finally, we note that this calculus has canonical forms as shown in [PP99a]. 
Thus all terms of functional type may be converted to the form Xx'.A. M or 
Xz:A. M\ all terms of conjunctive type may be converted to pairs {M , N)-, and 
all objects of atomic type may be reduced to a constant applied to zero or more 
canonical objects. 

The existence of canonical forms for this simple implicational fragment of 
OLL provides a basis for an ordered logical framework. We conjecture that an 
ordered logical framework based on a full type theory can be constructed along 
the lines of the linear logical framework [CP99]. In this paper we only need a 
two-level fragment as explained in subsection 2.2. 



2.2 Two-Level Framework 

We extend the ordered A-calculus from subsection 2.1 to a simple two-level logical 
framework where level-2 types will be allowed to depend upon level- 1 objects. 
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Thus level-2 type families p are indexed by level 1 objects M, and we can quantify 
only over level 1 objects. 



Level 2 types 
F ::= pMi . . . Mn 
I Fi^F2 
I Fi^ F2 
I Fit F2 
I T 

nx:A. F 



Level 2 objects 
D ::= c \ w \y 

I \w.F. D \ Di D2 
I )^y.F. D \ Di^ D2 
I {Di , D2) I 7Tl O I 7T2 O 

I 0 

I \x-.A.D\DM 



The extended typing judgement now has the form F] fi \- D ■. F , where F 
may contain declarations of the form x:A or w.F and fi contains declarations 
y.F. We omit the typing rules which are very similar to the propositional case, 
except that we now need rules for the dependent types: 

F,x-.A-,n^ D : F F-,n^ D : nx-.A. F T; • h M : T 

T; f? h \x:A. D : Hx-.A. F F- Q D M : F[M/x] 

and a rule for type conversion: 

F-Q\- D : F F; n \- F = 13 ^ F' 

F-Q\- D : F' 

Note that equivalence of level-2 types, =pt], must be decided in context due to 
the presence of T. 

Since we stratify the type theory into two syntactically distinct levels, Prj- 
equality for level-2 types immediately reduces to /3r?-equality for propositional 
objects. Since propositional objects possess canonical (= long /3r^-normal) forms, 
this equality is easy to decide, and type-checking in the fragment presented 
above can easily be seen to be decidable. Furthermore, canonical forms for level- 
2 objects likewise come as a consequence of level-1 objects having canonical 
forms. We will use the judgement F; fi \- D F to denote that object D is 
canonical at well-formed type F. 



3 Terms & Transforms 

This section introduces the direct-style language with exception raise and handle 
expressions, its CPS counterpart, and the transformation between them. We use 
underlined constants (e.g. handle ! and lambdas (A) to distinguish these objects 
from their OLF representations which are given in section 4. 

3.1 Direct Terms 

We use the following syntax for direct-style (DS) terms: 

DS Terms r ::= e 

DS Expressions e ::= eo ei | handle en (Aa;. ei) | raise e | t 

DS Trivial Expressions t \x. r \ x 
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Evaluating the expression raise e first evaluates e. It then aborts the normal ex- 
ecution and locates a handler by going up the current evaluation chain. The e’s 
value is passed to the handler. The handle expression handle en (Aa;.ei) evaluates 
bq. If eo raises an exception with value v and there are no other handle expres- 
sions between the current one and the raise expression, then the current handler 
function Aa;.ei handles it: the v is bound to a; in ei. Otherwise, the value of the 
handle expression is the value of bq. 

We define the formal semantics of DS terms with a structural operational 
semantics [PI08I] using Felleisen’s evaluation contexts [Fel87]. In doing so, we 
need to extend the expressions to contain a set of raised values t that are thrown 
from raise expressions: e ::= ■ ■ ■ \t. An evaluation context C is defined by the 
following grammar: 

C ::= [] \C e \ (Xx. r) C \ handle CAa;. e \ raise C 

This context defines a left-to-right, call-by-value reduction. As usual, we write 
C[e] if the hole in context C is filled with e. We use this context to define the 
reduction rule for arbitrary expressions: 

B b' 

C[e] ^ C{e'] 

The single reduction step b i-^- b' for a redex e consists of normal and exceptional 
reduction steps: 

Normal reduction steps Exceptional reduction steps 



(Aa;. r)t^ [t/a;]r 
handle t (Aa;. e) ^ t 



raise 1 1 -^- 1 
raise 1 1 -^- 1 

handle d lAa;. e) i-^- \plx\e 
te^t 
{Xx. r)t^t 



Normal reduction steps are not concerned with exceptions. Exceptional reduction 
steps specify the generation, propagation and handling of exceptions. 



3.2 CPS Terms 

Rather than working directly with DS terms, we transform them into CPS terms 
where the exception mechanism is captured by having a second (handler) con- 
tinuation in addition to the regular (success) continuation. This transformation 
exposes the semantics of exceptions in the program text. 

We use the following grammar for CPS terms: 



Root Terms 


r 


= Xk. e 




Serious Terms 


e 


= tohp 


1 ct 


Trivial Terms 


t 


= Xx. r 


X 1 V 


Continuation Pairs 


P 


= pair(cQ 


,ci)\k 


Continuation Terms 


c : 


= Xx. e 1 


Xv. e nrmi v hnd v 
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Note that in the CPS syntax, we are distinguishing variables x which are 
parameters of functions or continuations from variables v which are only param- 
eters to continuations. This distinction will be used to differentiate abstractions 
introduced by the transform from those already present in the DS term, nrmi 
and hnd are essentially the projections for the continuation pairs. 

The formal semantics are defined similarly to that for DS terms. However, 
rather than using special exception values (t ) ; exceptional flows ( raise and handle 
expressions) are simulated by continuation functions. Let 7 be the set of contin- 
uation functions: 7 ::= Xx.e \ Xv.e. An evaluation context C is extended for the 
cases of continuation pairs: 

C ::= [] \ C n\C t\rC \ pairlC' . cl | pairl^ . C) \ nrmI C \ hnd C 
The single reduction step e i-^- e' for a redex e is: 

Reduction steps 



(Aa;. r)t i-^- 

(Aa;. e)t [t/x]e nrmi pair (7o , 71) i-^- 70 

{Xv. e)t [t/v]e hnd pair(7o , 71) 71 

{Xk. e)pair(7o , 71) [pair(7o , 7 i)/^]e 



3.3 Continuation-passing-style (CPS) Transformation 

We use an extension of the conventional continuation-passing-style (CPS) trans- 
formation [DF92,Plo75,Ste78] to get from a DS term to a CPS term. We remove 
the raise and handle expressions by passing two continuations to each expres- 
sion: one for the normal course of execution, and a second one (the handler 
continuation) for exceptions. 

Only raise and handle expressions use the handler continuation. A raise ex- 
pression is transformed to call the current handler continuation. A handle ex- 
pression is transformed to extend the handler function with the current handler 
continuation. For other expressions, the handler continuation is simply passed 
along, reflecting the dynamic scope of exceptions. 

We show the extended CPS transform in a conventional functional notation. 

: DS Terms Root Terms 

[— ]'® : DS Expressions Continuation Pairs Serious Terms 
: DS Trivial Expressions Trivial Terms 

|el^ = X{n,h). [e]^ {n,h) 

leo eip {n,h) = |eop (A^'o- lei}^ {Xvi. vovi {n,h),h),h) 
[handle en {Xx. ei)]^ {n,h) =leo]^ {n,Xx. |eip (n,/i)) 

[raise ep (n,/i) = [ep {h,h) 

Itp(n,h)=n[tf 

Ixf = X 

[Aa;. rp = Aa;.[rp 
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Consider the transformation of an application, eo ei . If an uncaught exception 
occurs during the evaluation of eo, the handler h is invoked and the evaluation 
of eo ei is aborted. If an uncaught exception occurs during the evaluation of ei, 
after an intermediate value v<y has been computed for eo, the intermediate value 
Vo must be ignored by the handler h. Thus, however evaluation is implemented, 
invoking the middle occurence of h must be different from invoking the other 
occurrences of h, where there is no intermediate value to ignore. 

In order to reflect this distinction, and show that intermediate values really 
are stackable, we extend our CPS term syntax as follows: 

Continuation Terms c ::= ... | hnd' v v 

where v is the intermediate value which must be ignored. We also extend the 
evaluation contexts to include hnd' : C ::= . . . \ hnd' v C 

and add a reduction step for hnd' : hnd' v pair(7o , 71) 71 . 

Here is the extended CPS translation we will use, written in our exact CPS 
term syntax. 

Je]-^ = A^- [e]'® k 

|eo eipp = [eoppair(Auo. |eip pair(Aui. vovip, hnd' un n) , hndp) 
[handle eo (Aa;. ei)\^ p = [eo]'® pairf nrml y . Aa;. [eij-^p) 

[ raise e]'^ p = [e]'® pairl hnd v , hnd v) 

[tpp = (nimWf 

Ixf = X 

[Aa;. r]^ = Aa;.[r]^ 

Note the use of hnd' in the inner handler continuation of the application trans- 
lation. 

The correctness of this CPS transformation can be proven[KYD98] analo- 
gously to the proof of Plotkin’s simulation theorem [HD97,Plo75]. 

3.4 CPS Transformation as a Jndgement 

In order to represent the transform in OLF, we reformulate it as three mutually 
recursive judgements corresponding to [— ]^, [—1'®, and [— ]^ in section 3.3. A 
direct-style term r is transformed into a CPS term r' whenever the judgement 
h r — )■ r' is satisfied. Given a continuation pair p , a direct-style expression e 
is transformed into a CPS expression e' whenever the judgement \~ e ] p e' 
is satisfied. Finally, a direct-style trivial expression t is transformed into a CPS 

trivial expression t' whenever the judgement h t — )■ t' is satisfied. 

The derivation rules for the transform are as follows: 

h e ; e' 

h e \k. e h Aa:. r \x. r 

l_ ^ ^1 he; pairf hnd v , hnd v) e' 

h X — > X ^ i \ P — > ( nrmi p) t r raise e ; p — > e 
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h ei ; pair(Awi. wowip, hnd' «n v) e'l h eo ; pair(Awo- e'l , hnd v) e' 

, DE , 

h eo ei ; p — e 

r ei ; p — 6i r eo ; pair(nrrmp, \x. ei) — > e 
h handle en (Aa:. ei) ; p e' 

Note that the vq in the application rule is parametric in the left premise and 
cannot appear free in the right premise. 

3.5 Invariants for Resnlts of CPS Transform 

Terms resulting from a left-to-right call-by-value CPS translation of direct-style 
terms satisfy an invariant on occurrences of continuation identifiers k and param- 
eters V. We shall formalize this property with five mutually recursive judgements: 

l_Root ^ ^ |_Exp g ^ |_Triv ^ |_CPair ^ ^ |_Cont ^ 

where # is a stack of both continuation identifiers and parameters: 

# ::= • I A: I 

When is a prefix of we define # — as the remainder of 
The derivation rules for these judgements are as follows: 

k e 

\k. e 

# f; c # fi; to', p 

|_Root ^ 

# x-,$ # \x. r; # $,v v; # 

^ l^Cont go $ pCont Cj ^ |=Exp ^ „ |=Exp g 

^^CPair^ ^pCPair^^gO, Cl) # Aa:. 6 # A«. 6 

$ pCPair ^ ^ I^CPair ^ ^ |^CPair ^ 

# pCont ^ |_Cont j ^ .y |_Cont [^pj' .y ^ 

From the judgement rules, it is easy to see that continuation-pair identifiers, 
k, are used linearly in each root term, and that continuation parameters v (which 
were introduced by the CPS transform) form a stack in each serious term. In 
fact, the judgement actually implies the stronger property that continuation-pair 
identifiers and parameters are used together in a stack-like fashion. Each root 
term adds a new stack-frame, an identifier followed by parameters, which is fully 
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consumed within that root term. This is apparent from the judgement on Xx.r 
which requires that r not depend upon anything currently in the stack. 

We would like to prove that h r — )■ r' implies 1=^-°°* r' . Proving 
this directly with the above definitions requires a logical relations style argu- 
ment [DDP99,DP95]. However, by using an ordered logical framework, this may 
be proved directly. 

4 Ordered Logical Framework Representation 

In this section, we show how to represent the terms and transform of section 3 in 
OLF ; and how these representations immediately give our desired proof. Follow- 
ing standard practice for LF-style logical frameworks, we shall represent judge- 
ments as types and derivations as terms [HHP93] Furthermore, we will take 
care that all of our representations are compositional bijections — 1) for every 
actual object represented there is a corresponding OLF object (and vice-versa); 
and 2) the representation function and its inverse both commute with substi- 
tution. These two properties allow us to transfer results for the representations 
back to the actual objects and vice-versa. Representations which are composi- 
tional bijections are sometimes referred to as adequate. 

Our proof proceeds in the following manner. 

1. We give a representation for DS terms which is in compositional bijection 
with all actual DS terms. 

2. We give a representation for CPS terms which is in compositional bijection 
with only actual CPS terms satisfying the invariants; our representation does 
not capture all terms within the CPS grammar of section 3.2. 

3. We give a representation for the CPS transform of section 3.4. This represen- 
tation relates represented DS terms to represented CPS terms. Furthermore 
it is in compositional bijection with all possible CPS transformations (i.e. 
derivations of section 3.4). 

DR 

4. By using the preceding compositional bijections, we conclude that h r — > 

r' implies r' . 

4.1 DS Terms 

Our representation of DS terms will use three basic types corresponding to the 
three kinds of DS terms. 

droot : type. dexp : type. dtriv : type. 

We will then build our representations from term constructors corresponding to 
DS terms. Note that representation uses higher-order abstract syntax, so object- 
level functions are represented by meta-level functions and likewise object-level 

^ For representing abstract syntax (e.g. DS terms) we may view each syntactic category 
as a judgement and the constructors for terms of the category as derivation rules for 
the judgement. 




Proving Syntactic Properties of Exceptions in an Ordered Logical Framework 7 1 



variables are represented (implicitly) by meta-level variables. 



e2r : dexp — )• droot t2e : dtriv — )• dexp 

dapp : dexp — )• dexp — )• dexp dabort : dtriv 

handle : dexp — )• (dexp — )• dexp) — >■ dexp diam : (triv — )• droot) — t dtriv 

raise : dexp — )• dexp 



Given the previous signature, there is an obvious compositional bijection be- 
tween DS terms and canonical objects in the above signature. This bijection is es- 
tablished by the following mutually recursive representation functions, 
and their inverses l — j^,l— — j^. 

= e2r ce2r E^r = ^_E^E 

''eo ei"'^ = dapp cdapp Eq Ei_ie = \-Eo_ie \-Ei_ie 



'~ handle en (Aa:. ei)"'^ 
chandleiSo (Aa::dtriv. Ei)_ie 

'" raise e~'^ = raise 

= d2eT^ 

’~\x. = dIam (Aa::dtriv. 



handle'”eo''^ (Aa::dtriv. ''ei''^) 
handle ciSn-iK (As:. \^Ei_ie) 



Lraisei5_i_B = raise \-E_ie 
Ld2eT_i£ = lT_it 
cdlam (Aa::dtriv. i?)_iT = \x. \-R-ir 
ls:_it = X 



4.2 CPS Terms 

Next, we give a representation of CPS terms satisfying the invariants of sec- 
tion 3.5. The key idea behind this representation is that ordered types implicitly 
capture the invariants. Thus, we can directly represent CPS terms which satisfy 
the invariants, without explicitly representing the invariants. Our representation 
will use five basic types corresponding to the five basic kinds of CPS terms. 



root : type. exp : type. triv : type. cont : type. cpair : type. 



We will then build our representations from term constructors corresponding 



to CPS terms. The use of ordered types 
satisfy the invariants. 

klam : (cpair -» exp) — )• root 
app : cpair -» triv -» triv -» exp 
kapp : cont -» triv -» exp 
lam : (triv — )• root) — )• triv 
xiam : (triv — )• exp) -» cont 



forces the CPS term representations to 

vlam : (triv -» exp) -» cont 
nrmi : cpair -» cont 
hnd : cpair -» cont 
hnd' : cpair -» triv -» cont 
pair : (cont & cont) -» cpair 



Note that a positive occurrence of an unrestricted function as in the type of 
klam imposes a restriction on the corresponding argument: it may not depend 
upon continuation-pairs k nor parameters v which are always ordered variables. 
On the other hand, a negative occurrence of as in the type of lam licenses 
the unrestricted use of the corresponding bound variable x. The right ordered 
functions ^ impose the stack-like discipline on parameters of continuations and 
the continuation-pairs themselves. 
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Given the previous signature, there is a compositional bijection between CPS 
terms satisfying the occurrence conditions and canonical objects in the above 
signature. This bijection is established by the following representation function, 
and its inverse l— j. 



'"A/fc. e'' : 
''to tip"' ■ 
’■Cf : 
’~\x. r~' : 



r„-i 



klam (A fc:cpair. ''e'') 

kapp^''c''^T 
lam (Ax:triv. '"r"') 

X 

V 



_klam (A k:cpa\r. E)_i 

Lapp^P^To^Tij 
Lkapp^G^Tj 
Liam (Aa::triv. R)_i 

l2:_i 

LW_I 



^\x. 


= xiam ^ (Aa::triv. ''e'') 


Lxiam ^ (Aa::triv. P)_i 


''Aw. e'' 


= vlam (A w:triv. ''e'') 


Lviam (A w:triv. P)_i 


''nrmI p~' 


= (nrml^''p'') 


LnrmI P_i 


''hnd v~' 


= (hnd^''p'') 


Lhnd^Pj 


''hnd' tv~' 


= (hnd'"'''p''^''r') 


Lhnd'^P^Pj 


''k^ 


= k 


L^J 


''pair(co , Cl)'' 


= pair^Cco'', ''ci'') 


Lpair (Go,Gi)_i 



= \k. \-E_i 
= lTo_i lTi _1 lP_i 
= lG_i lTj 
= \x. lPj 

= X 
= V 

= \x. lPj 
= Aw. lPj 
= nrmi lP_i 
= hnd lP-i 
= hnd' lT-i lP-i 
= k 

= pair(LCo-i , lGi 



Note that and = u for any term u. Additionally, since variables are 

mapped to variables, the representation function and its inverse are composi- 
tional (i.e., commute with substitution). 

Finally we extend and l — j to stacks and contexts as follows: 



fc"' = fc:cpair w"' = w:triv 

L-_i = • \-fI,k:cpa\r_i = \_fi_i,k l/?, w:triv_i = Li7_i, w 

We formally prove the correspondence in two parts. 

Theorem 2 (Representations are Canonical Forms). 

Consider CPS terms r, e, t, c and p with free ordinary variables among xi, . . . ,Xn- 
Let r = a;i :triv . . . a;„:triv. 

1. If 1=**-°°* r then P; • h '~r~' ff mot. 

2. If$ e then P; h ''e'' fr exp. 

3. If$ t; then P; h T fr triv. 

4. If$ c then P; h ''c^ fr cont. 

5. If (I pCfair ^ p. r^-l |_ Tp-I .jl cpair. 



Proof: By induction on the structure of the given derivations. □ 

Theorem 3 (Canonical Forms are Representations). 

Let r = x\ :triv, . . . , a;„ :triv he given. 

1. For any M such that F-, ■ M root, 
lM_i is defined and |=**-°°* lM_i. 

2. For any Q = wi:triv, . . . , Wm:triv and M such that P; fc:cpair, i? h M ff exp, 

lM_i is defined and Li7_i lM_i. 
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3. For any Q = widriv, . . . ,Wm:triv and M such that P; h M fi triv, 



_M_i is defined and Li7_i N* 



_M_i; # for any 



4- For any Q = widriv, . . . , Wm:triv and M such that F\ fc:cpair, Q\- M cont, 



_M_i is defined and Li7_i 



_M_i. 



5. For any Q = widriv, . . . , Wm:triv and M such that F\ fc:cpair, Q\- M cpair, 



_M_i is defined and Li7_i 1= 



CPair 



,M_i. 



Proof: By induction on the structure of the given canonical derivations. For the 
cases when M = lam (Aa;:triv. r), and M = klam (A A:: (triv exp), e) note that 
the ordered context fi must be empty since no ordered variables can occur in 
the argument to an intuitionistic application. □ 



5 CPS Transform 



We represent CPS transform with three basic types corresponding to the three 
judgements of the transform. 

cps_r : droot— >root— >type. cps_e : dexp— repair— >exp-)-type. cps_t : dtriv— >triv— >type. 

We then use the following terms to construct representations of the CPS trans- 
form. 

cps_root : iTi5:dexp. iTiS'xpair -» exp. 

(iTAxpair. cps_ei5A: (E'^k)) — )• cps_r(e2ri5) (klamiS'). 

cps_triv : iTT:dtriv. iTPxpair. iTTbtriv. 

cps.tTT' ^-cps.e(t2eT)P(kapp^(nrml^P)^T'). 

cps_raise : PP:dexp. PP':exp. PPxpair. 

cps_eP(pair^(hnd^P, hnd^P))P'-)- 
cps_e (raise E) P E' . 

cps_app : PPo:dexp. PPi:dexp. PPxpair. PP(:triv -» exp. IIE':exp. 
cps_e Eo (pair^ (vlam , hnd^P)) P'— )• 

(Pwodriv. cps_e Pi 

(pair (vlam Awidriv. app P Wo wi , hnd’ P wo))(P( wo))-)- 
cps_e (dapp Po Pi) P E' . 

cps_handle : PPo:dexp. PPi:dtriv — )• droot. PPpdtriv — )• droot. PPxpair. IIE':exp. 
cps_e Po (pair^ (nrmi ^P , xiam ^P()) P'— )• 

(Pa::dtriv. Pa:':triv. cps_ta:a:' — )• cps_e (Pi x) P {E[ x'))^ 
cps_e (handlePo Pi) PE'. 

cpsJam : PP:dtriv — )• droot. UR' :tm — )• root. 

(Pa::dtriv. IIx':tnv. cps_t a: a:' — )• cps_r (Rx) (P'a:'))— )• 
cps_t (diam R) (lam R'). 



We may now show the adequacy of the above representation in two parts. 
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In the actual transformation we map variables x to themselves; in the repre- 
sentation we map each variable x from a DS term to a corresponding variable x' 
in a CPS term^. These variables and their relationship are captured in contexts 

r = a;i:dtriv . . . Xn'-dtm 
r’ = x’x'.tm . . . x’n'-tm 
Fm = mi:cps_ta:i x'l . . . m„:cps-t x„ x'n 

which always occur together in this manner. In addition we have contexts 

Fk = fci:cpair . . . km'-cpa\r 
Fy = wi:triv . . . wptriv 

which include all the continuation-pair identifiers k and temporary variables v 
which may occur in the continuation-pair p and CPS terms resulting from the 
translation. Note that ordering constraints are ignored during the translation, 
but will be nonetheless be satisfied by the resulting terms. 

Theorem 4 (Representations are Canonical Forms). 

Let r* = r, r' , Fm, Fi^, Fy be a eontext of the form explained above whieh eon- 
tains all free variables oeeurring in the relevant judgement. Then 

1. \- r r' implies 3M. T*; • h M -(!■ cps_r ''P'' 

2. h e ; p e' and # p implies 3M. T*; • h M ff cps_e '”p'"'e''' 

5. \- t t' implies 3M. T*; • h M ff cps_t '’t'"' 

Proof: By structural induction on the given derivation. For part 2, note that 
will be part of T*. □ 

Theorem 5 (Canonical Forms are Representations). LetF* = F,F',F^,Fk,F, 
a eontext of the form explained above and assume the types below are eanonieal. 

1. F*\ ■ \- M cps_ri?i?' implies h i-R-ir 

2. F* M 'll cps-e E P E' implies h lFjb ; lP_i lF'j. 

3. r*;-l-Mfrcps.tTT' implies h lT_,t lT'-i. 

Proof: By structural induction on the given canonical derivation. □ 

The adequacy of our representation gives us a simple proof that the terms 
resulting from a CPS transformation satisfy the occurrence conditions of sec- 
tion 3.2. 

Theorem 6. h r r' implies r' . 

Proof: Suppose r is closed. 

By theorem 4 we know 3M. • h M ff cps_r 

Then we know • h '"r'”' ft' i"oot from inversion on canonical typing rules. 

Then by theorem 3 we know vFr'^j. 

Then we are done since L'”r'”'j = r'. 

Same reasoning applies for open r except that we will have to strengthen away 
unnecessary hypotheses from the unrestricted context before going from 2nd to 
3rd step. □ 

This is accomplished by the cpsJam rule. 



3 
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The simplicity of the proof above may be surprising. It is so direct, because 
the work has been distributed to the proof of the adequacy theorems (which are 
clearly not trivial) , combined with some deep properties of the logical framework 
such as the existence of canonical forms. This factoring of effort is typical in the 
use of logical frameworks. 

6 Related Work 

Berdine, O’Hearn, Reddy and Thielecke have shown that the CPS transform 
with exceptions produces CPS terms which use their continuation-pair argu- 
ment linearly [BORTOl]. This work refines that analysis and shows that the 
immediate result of the transform actually uses the continuation-pair argument 
in an ordered fashion. However, our results are brittle in the sense that the order- 
ing property is not preserved by arbitrary (3 reduction — (3 reducing underneath 
a lambda could result in a term which doesn’t satisfy the ordering invariants. 

In [PPOO], Polakow and Pfenning show how OLF provides a convenient set- 
ting for reasoning about the CPS transform which doesn’t treat exceptions. This 
work shows how those representation techniques easily extend to treat the CPS 
transform which removes exceptions. 

In [DanOO], Danvy shows how to implement evaluation for a language with 
first-class continuations while still leveraging the stackability properties of second- 
class continuations. His analysis is quite similar in spirit to this work. Where 
we keep the distinction between (second-class) continuations introduced by the 
transform and handlers provided by the user, Danvy distinguishes between second- 
class and first-class continuations. Furthermore, we speculate that Danvy’s anal- 
ysis could be naturally re-cast in OLF. 

7 Conclusion & Future Work 

We formally proved the stackability and linearity of exception handlers with ML- 
style semantics using the help of an ordered logical framework (OLF) [PPOO]. We 
transformed exceptions into continuation-passing-style (CPS) terms and formal- 
izeed the exception properties as a judgement on the CPS terms. Then, rather 
than directly proving that the properties hold for terms, we proved our theorem 
for OLF representations of the CPS terms and transform. We used the correct- 
ness of our representations to transfer the results back to the actual CPS terms 
and transform. We further showed that the results in [DP95,DDP99] carry-over 
to the extended CPS transform which removes exceptions. Working with OLF 
representations allowed for a relatively simple proof in which we could directly 
use known properties of OLF terms (e.g. substitution properties) rather than 
re-proving similar properties for actual CPS terms satisfying our invariants. 

We can also extend our analysis to cover evaluation of CPS terms. The invari- 
ants satisfied by CPS-transformed terms clearly suggest a stack-like evaluation 
mechanism. In fact, we can show (though space doesn’t permit it in this paper) 
that a stack-like evaluation machine for CPS terms, which takes advantage of 
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the ordering invariants, behaves the same as a regular evaluation machine which 
always uses substitution. 

Our work can be seen as two-fold: it is a theoretical justification of existing 
compilers that use the stack mechanism to implement exceptions; and it demon- 
strates the value of a (ordered) logical framework as a conceptual tool in the 
theoretical study of programming languages. We conjecture that many systems 
with constrained resource access will have a natural representation in an ordered 
logical framework. 
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Abstract. A lambda-encoding such as the CPS transformation gives 
rise to administrative redexes. In his seminal article “Call-by-name, call- 
by- value and the lambda-calculus” , 25 years ago, Plotkin tackled admin- 
istrative reductions using a so-called colon translation. In “Represent- 
ing control, a study of the CPS transformation”, 15 years later, Danvy 
and Filinski integrated administrative reductions in the CPS transfor- 
mation, making it operate in one pass. This one-pass transformation 
is higher-order, and can be used for other lambda-encodings, but we do 
not see its associated proof technique used in practice — instead, Plotkin’s 
colon translation appears to be favored. Therefore, in an attempt to link 
the higher-order transformation and Plotkin’s proof technique, we recast 
Plotkin’s proof of Indifference and Simulation in a higher-order setting. 
To this end, we extend the colon translation from first order to higher 
order. 

Keywords. Call by name, call by value, A-calculus, continuation-passing 
style (CPS), CPS transformation, administrative reductions, colon trans- 
lation, one-pass CPS transformation, Indifference, Simulation. 



1 Introduction 

In “Call-by-name, call-by- value and the A-calculus” [9], Plotkin provided the 
first formalization of the transformation into continuation-passing style (CPS) 
[10, 11]. Plotkin’s CPS transformation is first-order. As most A-encodings, it is 
plagued with so-called administrative redexes, i.e., redexes that are only artefacts 
of the A-encoding. Their reduction steps are interspersed with the reduction steps 
corresponding to actual reduction steps in the original direct-style program. In 
the early 90s, a higher-order version of the CPS transformation was developed 
that eliminates all administrative redexes at transformation time, in one pass [1, 
3,12]. This higher-order version has been formalized in several ways: using a 
notion of ‘schematic’ continuations [3], using higher-order rewriting [4], and using 
logical relations [2]. None of these various ways of formalizing a one-pass CPS 
transformation, however, match Plotkin’s original proof technique. 
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Does it mean that Plotkin’s proof technique is inherently first-order? In this 
article, we answer this question negatively. We adapt his proof technique to the 
higher-order setting of one-pass CPS transformations. 

To tackle administrative reductions, in his formalization, Plotkin introduced 
a so-called colon translation that eliminates administrative redexes until a redex 
is reached that corresponds to an actual redex in the original program. Our goal 
here is to present a higher-order colon translation that yields the same effect for 
a one-pass CPS transformation, thus adapting Plotkin’s original proof technique 
to a higher-order operational setting. 

Prerequisites: We assume a basic familiarity with Plotkin’s work, as can be gath- 
ered from his original article [9] or from Hatcliff and Danvy’s revisitation [7]. The 
one-pass CPS transformation is presented in Danvy and Filinski’s article [3] (Sec- 
tion 3 of that article reviews administrative redexes and the colon translation) . 
A pictorial presentation of actual and administrative reductions can be found 
in Section 3 of Danvy, Dzafic, and Pfenning’s 1999 article [2]. Nevertheless, we 
have tried to make the present article stand alone. 

Overview: Section 2 reviews call by name and call by value in the untyped A- 
calculus. Sections 3 and 4 present the one-pass CPS transformation and its meta- 
language. Section 5 states our goal (proving Plotkin’s Indifference and Simulation 
theorems) and our means (a higher-order colon translation). Section 6 recasts 
Plotkin’s four lemmas and Section 7 restates his proof. Section 8 concludes. 

2 Call-by-name and call-by-valne A-calculi 

We define the untyped A-calculus by giving its syntax and two semantics, one 
for call by value (CBV) and the other for call by name (CBN). 

Definition 1 (Syntax of the A-calculus with uninterpreted constants). 

e::= X \ Xx.e | e@ e | c 

We only distinguish expressions up to renaming of bound variables. So for 
example, Xx.x and Xy.y are considered equal. 

2.1 Call by value 

The CBV semantics of closed expressions is given using evaluation contexts in 
the style of Felleisen [5] . 

The evaluation contexts are as follows. 

Cv[]::=[] |Cv[]@e|uv@Cv[] 



where Vv is a value. 
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Values form a subset of expressions and are defined as follows. 

Wv "= \x.e I c 

The reduction rule is defined as follows. 

Cv[(Aa;.e) @ Wv] ' — >v Cv[e[wv/a;]] 

where e[v/x] is the standard capture-avoiding substitution. 

EvaLv is the following partial function: 

J EvALv(e) = Vv iff e i — Vv for some value and integer i 

[ EvALv(e) is undefined otherwise 

where i — denotes i iterations of i — >v 



2.2 Call by name 

We give the CBN semantics for closed expressions as in Section 2.1. 
The evaluation contexts are: 



C„[] ::= [] I Cn[]@e 



The values are: 



The reduction rule is: 



Vn ::= Ax.e | c 



C„[(Ax.e) @ e'J i — C„[e[e7a;]] 

EvALn is the following partial function: 

J EVALn(e) = Vn iff 6 I — >n for some value Vn and integer i 

\ EvALn(e) is undefined otherwise 



2.3 Evaluation-order independent reduction 

In the remainder of this article, the arrow i — > (without annotation) corresponds 
to a reduction that is legal in both call by value and call by name. In other 
words, the i — > relation is the intersection of the i — >v and i — >n relations. 



2.4 Stuck terms 

In both the call-by-value and the call-by-name semantics, we can write closed 
expressions that are not values, but for which there are no legal reductions. 
Plotkin said that such expressions “stick” . 

The stuck closed expressions w.r.t. the CBV semantics are: 

Sticksv ::= c@Vy | Sticksv @ e | @ Sticksv 



or simply Cv[c@r!v]. 
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The stuck expressions are disjoint from the values. All closed expressions are 
either values, stuck, or there is a possible reduction. 

The stuck closed expressions w.r.t. the CBN semantics are: 

Sticksn ::= Sticksn @ e | c@e 



or simply Cn[c@ e]. 

Again the stuck expressions are disjoint from the values, and all closed ex- 
pressions are either values, stuck, or allow a reduction. 

3 The meta language of the one-pass CPS transformation 

The one-pass CPS transformation maps direct-style A-expressions into A-expr- 
essions that can be reduced at transformation time, yielding A-expressions in 
CPS. Therefore, the implementation language for the transformation contains 
two kinds of applications, two kinds of A-abstractions, and two kinds of variables: 

E::=c\x\ Xx.E \E @E\X \ XX.E \ E @E 

Following tradition we refer to overlined constructs as static and non-overlined 
ones as dynamic. The identifiers ranged over by X and x are called static and 
dynamic variables, respectively. Substituting an expression for a static variable 
is a static substitution, and substituting an expression for a dynamic variable is 
a dynamic substitution. As in Section 2, we only distinguish expressions up to 
renaming of bound variables, both for static and dynamic variables. 

We define the following typing system for the meta language: 

r ::= Syntax | t ^ t 



r\- E : Syntax 

The: Syntax E \- x : Syntax E h Xx.E : Syntax 

E \- Eo : Syntax E \- Ei : Syntax A(A) = r 

E \- Eo@Ei : Syntax E \- X : t 

E, X : T\ \- E : T2 T h Tq : Ti — > T2 E \- Ei : ti 

E h XX.E : Ti — > T2 E \- Eq @ El : T2 

Any expression typeable in this typing system is simply typed and hence its 
reduction terminates and any evaluation strategy leads to the same normal form. 
We choose to use call by value, arbitrarily. 

The meta-language values are: 

uv ::= c I X I Xx.vy | uv @ W I XX.E 

N.B. If a meta-language value vy has type Syntax, it is an expression in the 
A-calculus as defined in Section 2. In particular, vy is free of static variables. 
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The evaluation contexts are: 

Cv[] ::=[]! Ax.Cv[] | Cv[]@£; | w@Cy[] | Cv[]@^^ I w@Cv[] 

The reduction rule only allows us to reduce static /3-redexes: 

Cv[(AX.i?) @ vy] I >y Gy[E[v\ / X\\ 

Proposition 1 (Context nesting). Since nested contexts are themselves con- 
texts, the reduction rule satisfies the following property. 

E I >y E' <1=^ Cy[i?] I >y Cy[E'] 



Proof. Omitted. □ 

We define the static evaluation function, EvALy, by 
EVALy(i?) = Wy E i >y Vy 

where i — >y denotes zero or more iterations of i — >y. By definition reductions 
on well-typed expressions are strongly normalizing, so EvALy is total on these. 

We treat the meta language as a higher-order language in the sense that we 
equate expressions up to /3-equivalence (written =y). We only use simply typed 
and thus strongly normalizing expressions, so we can equate any expression to 
the value it reduces to. 

The dynamic substitution of a closed value, as used for A-expressions in 
Section 2, can be extended directly to meta-language terms. The interaction 
between static and dynamic substitutions satisfies the following property. 

Proposition 2 (Substitution). If E is a meta-language expression, vy is a 
meta-language value, and e is a closed X-expression, then 

E[vy /X][e/x] = E[e/x][vy[e/x]/ X]. 

Proof. By structural induction on E. 

Cases E = c, X, and Y {Y X)-. In these cases X is not free in E, and hence 
X is not free in E\e/x\. It follows that 

E[vy / X][e/x] = E[e/x] = E[e/x][vy[e/x]/X]. 

Cases E = El @ E2 and Ei@E2'. These cases both follow directly from the in- 
duction hypothesis and the definition of substitution. 

Case E = X: X[vy/X][e/x\ = vy[e/x] = X[e/ x][vy[e/ x]/ X] 

Case E = Xy.E\ and XY.Ei', Since we equate expressions up to alpha-renaming 
of bound variables, we can assume that y is not free in vy and y x as well 
as F X. These cases are thus similar to the Ei @ E2 case. 



□ 
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Corollary 1 (Dynamic substitution respects static /3-equivalence). If E 

and E' are meta-language expressions, v is a value, and x is a dynamic variable, 
then 

E I — E' E[v/x] I — E'[v/x\. 

I.e., if E =v E' then E[v/x] =v E'[v/x\. 

Proof It suffices to show that if E i — >v E' then E[v/x] i — >v E'[v/x]. Since 
E I — >v E only if there exists a context Cv[ ] such that E = Cv[(AX.ifi) @ V] 

I — >v Cw[Ei\V/X\\ = E', the proof is by induction on the structure of the 
context. 

Case Cv[ ] = [ ]: In this case E = (XX. Ei) @ V and E' = E\^jX\. 

((XX.Ei)@V)[v/x\ = (\X.Ei[v/x])@V[v/x] 

I — >v Ei[v/x][V[v/x]/X] 

= Ei\V/X][v/x] by Proposition 2 



Case Cv[] = Ci[]@^; 2 : 

E[v/x] = Gi[(\X.Ei)@V][vJ_x] 

= (Ci[Q(X.Ei)@V]@E 2 )[v/x] 

= Ci[(XX.Ei)@V][v/x\@E 2 [v/x] 

I — >v @E 2 [v/x] by I.H. and Proposition I 

= (Ci[E^[V/X]]@E2)[v/x\ 

= Gw[Ei[V/X]][v/x] 

= E'[v/x\ 

Cases Cv[ ] = Ci[ ] @ E 2 , Ci[ ], Ci[ ], and Aj/.Ci[ ]: Similar to the pre- 
vious case. 

□ 

This corollary shows that we can use an arbitrary representative for the equiv- 
alence classes up to =v when performing dynamic reductions. Therefore, in the 
remainder of this article, we will use = instead of =y. 



4 The one-pass CPS transformation 

We consider the one-pass version of Plotkin’s (left-to-right) call-by-value CPS 
transformation [3]. (Many others exist, depending, e.g., on the evaluation order 
of the source language [6].) 

The one-pass CPS transformation is defined inductively with the two func- 
tions |-] and |-]' displayed in Figure 1. Whereas Plotkin’s CPS transforma- 
tion uses only one function, the one-pass transformation uses two, depending 
on whether the continuation is known statically (|-]) or not (!•]') • These two 
functions map A-expressions as defined in Section 2 to expressions in the meta 
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[•] ; Syntax ^ (Syntax ^ Syntax) ^ Syntax 
[c] = AK.K@c 
[x] = AK.K@x 

[Ax.e] = AK.K@Ax.Ak.[e]'@k 
|ei @ 62] = AK.[ei] @ AVi.[e2] @ AV2 .Vi @ V2 @ Av.K @ v 

[•]' : Syntax ^ Syntax ^ Syntax 
[c]' = AK.K@c 
Ix]' = AK.K@x 
[Ax.e]' = AK.K@Ax.Ak.[e]'@k 
[ei @ 62]' = AK.Iei] @ AVi.[e2] @ AV2.V1 @ V2 @ K 

The transformation uses some fixed variables that are assumed to be “fresh” , 
i.e., that do not occur in the program to be transformed. These variables are 
denoted by ‘k’ and ‘v’, which are dynamic variables. We also fix the static 
variables K, Vi, and V2. The static variables cannot clash with variables in 
the original program, but they must be distinct. All these fresh variables are 
written in Roman font. 

Fig. 1. The left-to-right, call-by-value CPS transformation in one pass 



language defined in Section 3. Their type are easily inferred using the rules of 
Section 3. 

We define the function 9 to map direct-style values to CPS values: 

'f'(c) = c 

'F(Xx.e) = Ax.Ak.|e]'@k 

N.B. |vvl = AK.K@if(uv) a^d Kl' = AK.K @ if (uv). 

The two-level ? 7 -redex Av.«;@v coerces a meta-language expression of type 
Syntax ^ Syntax into a meta-language expression of type Syntax, and there- 
fore, the two CPS-transformation functions are related as follows. 

Proposition 3. If e is a X-expression and k is a meta-language expression of 
type Syntax ^ Syntax then 

\e\' @ \v.K @ V I — >* |e] @ K 

remembering that we equate expressions up to static (3-equivalence and that the 
identifier v is fresh, so it is not free in k. 

Proof. By structural induction on e. 
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Case e = x: 

|x]'@Av.k@v = {Xv.K@v)@X 
I — > K@v[a;/v] 

= K@x by Corollary 1 

= |x] @ K 

Case e = Acc.ei: 

|Ax.ei]' @ Av.k@ V = (Av.k@v) @!P(Xx.ei) 

I — > v[lf"(Ax.ei)/v] 

= K@!Z/(Ax.ei) 

= |Ax.ei] @ K 

Case e = Cl @ 62: 

|ei @ 62 ]' @ Av.tt @ V = Id] @ AVi.|e 2 | @ AV 2 .V 1 @ V 2 @ Av.k@ v 
= |ei @ 62] @ K 

□ 



5 The goal 

Plotkin proved three properties of the CPS transformation: Indifference, Simu- 
lation, and Translation. We prove the first two for the one-pass CPS transfor- 
mation. 

Theorem 1 (Indifference). EvALv(|e] @ AV.V) = EvALn(|e| @ AV.V). 

The Indifference theorem formalizes a key property of CPS, namely that CPS 
programs are evaluation-order independent. 

Theorem 2 (Simulation). EvALv(|e| @ AV.V) = 'f'(EvALv(e)). 

where was defined in Section 4, just before Proposition 3. 

The Simulation theorem formalizes the correctness of the call-by-value CPS 
transformation. For one point, the theorem shows that termination is preserved, 
but more essentially, it says that evaluating a CPS-transformed program yields 
the CPS counterpart of the result of evaluating the original program. 

To prove Indifference and Simulation, Plotkin used four lemmas. We prove 
the same four lemmas for the one-pass CPS transformation. Plotkin’s proof then 
applies as is (see Section 7). 

To handle administrative redexes, Plotkin introduced a colon translation. 
This translation is an infix operation mapping an expression and a continuation 
to the CPS counterpart of that expression applied to the continuation, but by- 
passing the initial administrative redexes introduced by the CPS transformation. 
To account for meta-level reductions at CPS-transformation time, we define a 
higher-order version of Plotkin’s colon translation. 
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Definition 2 (Higher-order colon translation). 

c : K = K@^{c) 

Xx.e : K = K@'P{Xx.e) 

Vi@V2 : K = >P(vi) @>P(V2) @ Xv.K@ V 

vi@e2.'K = 62 : XV2-’^'(vi) @ V2 @ Xv.K@ V 62 not a value 

ei@62 : K = Cl ; A yi.|e2] @ A ^2- 1^1 @ V2 @ Auk @ V e\ not a value 

Unlike Plotkin’s colon translation, which is first order and interspersed with 
the actual reductions, this colon translation is higher order (as indicated by 
the overlines) and its static, administrative reductions occur before the actual, 
dynamic reductions. 

6 Plotkin’s four lemmas 

Lemma 1 (Substitution lemma). 

For all X-expressions e and all closed values v and variables x, 

le\[F{v)/x\ = [e[v/x\l 
leY[^{v)/x] = |e[w/x]l' 

Proof. By structural induction on e. 

Cs-S© c ^ XI 

|x][if'(u)/a;] = (AK.K@cc)[>f"(v)/a;] 

= AK.K@if(u) 

= H 

= {x[v/x]\ 

Case e = y: 

lyl[F{v)/x] = QiK.K@y)['F{v)/x] 

= XK.K@y 
= ly[v/x]] 

Case e = Xy.ei, where y x 

lXy.ei}['F{v)/x] = ^AK.K@ Ai/.Ak.|ei]'^k)[tf^(v)/x] 

= AK.K @ ((Ay. Ak. |eil' @ k) /x\) 

= AK.K@(Ay.Ak.|eil'[tf^(v)^]@k) 

= AK.K @ (Ay.Ak.|ei[v/x]]' @k) by I.H. 

= IAy-ei[v^]| 

Case e = Cl @ 62 : 

\ei@e2}['I'{vyx] _ 

= AK.(|ei] @ AVi.|e2] @ AV2.V1 @ V2 @ Av.K @ v)[<f"(w) /x] 

= AK.(|ei] fF{v)/x\) @ AVi.(|e2][!f"(w)/x]) @ AV2.V1 @ V2 @ Av.K @ v 
= AK.|ei[w/a;]] @ AVi.|e2[w/a;]] @ AV2.V1 @ V2 @ Av./t @ v by I.H. 

= |ei[w/a;] @e2[u/x]] 

= |(ei@e2)[u/x]] 
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The cases for |-]' are similar. □ 

Lemma 2 (Administrative reductions). 

If e is a closed X-expression and k is a closed meta-language expression of type 
Syntax ^ Syntax then |e] @ n i — >y e : k (i.e., they are equal modulo =y). 

Proof. By structural induction on e. 

Case e = c: _ 

|c] @ K = (AK.K @c)@ K 
I >v K@c 

= Cl K 

Case e = Acc.ei: 



|Acc.ei]@K = (AK.K @ tf"(Ax.ei)) @ /t 

I — >v n@I'{Xx.ei) 

= Ax. Cl : K 



Case e = Ti @ V2'- 

|ui@'C2]@k = (AK.|ui] @ AVi.|w 2] @ AV2.V1 @ V2 @ Av.K @ v) @ /t 

= {XK.(^K.}^<P{^))@ _ _ 

AVi . (AK.K @ If (^)) @ AV2 . Vi @ V2 @ Av.K @ v)@k 
I If (ui) @ If (W2) @ Xv.K @ V 

= Vi@V2 '• K 



Case e = ui @ 62: 

|wi @ 62] @ K = (AK.|ui] @ AVi.|e2] @ AV2.V1 @ V2 @ Av.K @ v) @ 

= (AK.(AK.K@if(wi))@AVi.|e2]@AV2.Vi@V2@Av.K@v)@K 
I — >y |e2] @ AV2.!f (vi) @ V2 @ Av.K @ v 
I — >y 62 : AV2.!f (wi) @ V2 @ Av.K @ V by I.H. 

= Wi @ 62 : K 



Case 6 = 6i @ 62: 

|ei@62]@K = (AK.|ei] @ AV1.I62] @ AV2.V1 @ V2 @ Av.K @ v) @ K 
I — >v |ei] @ AV1.I62] @ AV2.V1 @ V2 @ Av.k@ V 
I — >y 61 : AV1.I62] @ AV2.V 1 @ V2 @ Av.K @ V by I.H. 

= 61 @ 62 : K 



This enumeration accounts for all expressions e. □ 

Lemma 3 (Single-step simulation). 

If e is a closed X-expression, k is a closed meta-language expression of type 
Syntax ^ Syntax, and e 1 — >v e' then e : k i — e' : k. 



Proof. By structural induction on the evaluation context in the derivation of 
6 I — >v e'. 



V 
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Case C[ ] = [ ], i.e., (Ax.e) @ v i — >v e[v/x\i 



{\x.e)@v-.K = \y.k@y 

= (Ax.Ak.|e]' @k) @ @ Av.k@ V 

I — > ((Ak.|e]' @ k)[if'(t))/x]) @ Av.k@ V 
= (Ak.|e]'[if"(v)/x] @k) @ Av.k@ V by Corollary 1 

= (Ak.|e[v/x]]' @ k) @ Av.k@ V by Lemma 1 

I — > |e[t'/x]]' @ (Av.k@ v) 

I — >* |e[t'/x]] @ K by Proposition 3 

= e[v/x] : K by Lemma 2 



Case C[ ] = Ci[ ] @ 62, i.e., Ci[ei] @ 62 ' — >v Ci[e'2] @ 62 derived from Ci 1 — >v e!\ 

Ci[ei]@e2:K = Ci[ei] : AVi.|e2] @ AV2.V1 @ V2 @ Av.k@ v 

I — >+ Ci[ei] : AVi.|e2] @ AV2.V1 @ V2 @ Av.k@ v by I.H. 

= e' to give it a name 

— If Ci[e'^] is not a value, then Ci[e^] @ 62 : k = e' 

— If Cl [e'l] is a value then 

^ = [62] @ AV2.('f'(Ci[ei]) @ V2) @ Xy.k@y 

= 62 : AV2.'f'(Ci[ei]) @ V2 @ (Av.k@ v) by Lemma 2 



• If 62 is not a value, then Ci[ei] @ 62 : k = e". 

• If 62 is a value, then 

e" = <f"(Ci[e'i]) @ <Z'(62) @ Av.k@ V 

= Cl [e'l] @62 : K 

Case C[ ] = wi @ Ci[ ], i.e., vi @ Ci[e2] ' — >v vi @ Ci[e2] derived from 62 ' — >v e'2 

wi@Ci[ 62 ]:k = Ci[e2] : AV2.’f"(wi) @ V 2 @ Av.k@ V 

I — Ci[ey : AV2.’f"(wi) @ V2 @ Av.k@ v by I.H. 

= e' 

— If Ci[ey is a not value then v\ @Ci[ey : k = e'. 

— If Cl [e^ is a value then 

e! = 'f'(ui) @ !f"(Ci[e2]) @ Ay.k@y 

= vi @ e '2 : K 



□ 



Lemma 4 (Coincidence of stuck expressions). 

If e G Sticksv and k is a closed meta-language expression with type Syntax 
Syntax, then e : k G Sticks„ H Sticksv . 

Proof. By induction on the structure of the stuck expression e. 
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Case e = c@v: 

(c@ w) : K = S'(c) @ i'(v) @ Xv.K @ V 
= c@ @ Xv.K @ V 

which is stuck since c@^'{v) is stuck both in call- by-name and call- by- value. 
Case e = vi@ 62 where 62 G Sticksv: 

(Ul @62) : K = 62 ■ AV2.'?'(ui) @ V2 @ Xv.K @ V 

which is stuck by induction hypothesis, 62 being closed and structurally 
smaller that e. 

Case e = Cl @ 62 where Ci G StickSv: 

(ei @ 62) : K = 61 : AVi.|e2] @ AV2.V1 @ V2 @ Av.tt@ v 

which is stuck by induction hypothesis, ei being closed and structurally 
smaller that e. 

□ 

7 Plotkin’s double proof 

Plotkin proved both Indifference and Simulation using four lemmas similar to 
the ones in the previous section. Let us restate his proof. 

Proof. We need to show that for any e, EvALv(|e] @ AV.V) and EvALn(|e] @ AV.V) 
either are both defined and yield the same result, which is 'f'(EvALv(e)), or they 
are both undefined. 

1 . If EvALv(e) = Vv (i.e., if e 1 — Vy for some i, by the definition of EvaLv(-) 
in Section 2 . 1 ) then 

|e] @ AV.V = e : AV.V 
I — rv : AV.V 
= (AV.V)@if(uv) 

= 'f(wv) 

= !f(EVALv(e)) 

Therefore EvALv(|e] @ AV.V) = <f"(EvALv(e)). Furthermore, Lemma 3 only 
uses reductions in 1 — >, and this relation is the intersection of the 1 — >v and 
I — >n relations. Therefore EvALv(|e] @ AV.V) = EvALn(|e] @ AV.V). 

2. If EvALv(e) is undefined then it is either because e reduces to a stuck term, 
or because e has an infinite reduction sequence. 

(a) In the first case there exists an e' G StickSv such that e 1 — e'. In that 
case 

|e] @ AV.V = e : AV.V by Lemma 2 

I — >* e' : AV.V by repeated use of Lemma 3 

G Sticksn n StickSv by Lemma 4 

In words, whether one uses call by name or call by value, |e] @ AV.V 
reduces to a stuck term. 



by Lemma 2 

by repeated use of Lemma 3 
since Vv is a value 
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(b) In the second case there exists a sequence of expressions 

e I Cl I C2 I ‘ ‘ ‘ ' Cyi I 



by Lemma 2 
by Lemma 3 
by Lemma 3 

by Lemma 3 

In words, |e] @ AV.V has an infinite reduction sequence too, both in call 
by name and in call by value. 

Together these two cases prove the Simulation and Indifference theorems. □ 

8 Conclusion 

We have adapted Plotkin’s four lemmas to the one-pass CPS transformation, 
which required us to introduce a higher-order colon translation. Given these 
four lemmas, Plotkin’s Indifference and Simulation theorems and their proof 
apply directly to validate the one-pass CPS transformation. 

Other A-encodings exist that give rise to administrative reductions — for ex- 
ample, in denotational semantics, the denotation of a program is obtained by 
a syntax-directed translation into the A-calculus. The resulting A-term contains 
many administrative redexes that need to be dealt with to reason about pro- 
grams. A good semantics-directed compiler is expected to eliminate these admin- 
istrative redexes at compile time. For example, an identifier is typically mapped 
into an application of the environment, and scope resolution is expected from a 
compiler, so that variables are looked up in constant time at run time. Factoring 
out administrative redexes at compile time (a.k.a. staging [8]) is accepted good 
practice. When the compiler is written in a higher-order functional language (say, 
ML), administrative reductions can be represented as ML reductions. What we 
have shown here is a way to prove the correctness of this higher-order represen- 
tation in the particular case of the CPS transformation. 

Acknowledgments: This work is supported by the ESPRIT Working Group 
APPSEM (http : //www.md. chalmers . se/Cs/Research/Semantics/APPSEM/). 
Part of it was carried out while the second author was visiting John Hannan 
at Penn State, in the fall of 2000. We are grateful to the anonymous reviewers 
and to Julia Lawall for perceptive comments. 



In that case 



|e] @ AV.V = e : AV.V 
I — >+ ei : AV.V 

I — >+ 62 : AV.V 
; ,.- 1 - 

e„ : AV.V 

, .-I- 
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Abstract. A systematic method of compiling lazy functional programs 
based on the Spineless Tagless G-machine (STGM) is presented for the 
Java Virtual Machine (JVM). A new specification of the STGM, which 
consists of a compiler and a reduction machine, is presented; the compiler 
translates a program in the STG language, which is the source language 
for the STGM, into a program in an intermediate language called L-code, 
and our reduction machine reduces the L-code program into an answer. 
With our representation for the reduction machine by the Java language, 
an L-code program is translated into a Java program simulating the 
reduction machine. 

The translated Java programs also run at a reasonable execution speed. 
Our experiment shows that execution times of translated benchmarks 
are competitive compared with those in a traditional Haskell interpreter. 
Hugs, particularly when Glasgow Haskell compiler’s STG-level optimiza- 
tions are applied. 



1 Introduction 

The motivation to compile functional languages for the Java Virtual Machine 
(JVM) [4] comes from the mobility of being able to run the same compiled code 
on any machine with a JVM, and the potential benefits of interlanguage working 
with Java. For implementors, the fact that every JVM is equipped with a built-in 
garbage collector may draw their attention. As a method of functional language 
implementations, this subject may be an interesting exploration of the strange 
nexus of functional languages, byte coded virtual machines, and object oriented 
programming. 

Our object is to develop a lazy functional language compiler based on the 
Spineless Tagless G-Machine (STGM) for the JVM. The reason for using the 
abstract machine is that it is the state of the art in lazy abstract machine and 
many optimizations are available for its source language, the Shared Term Graph 
(STG) [7] [8]. 

There have already been two similar attempts to do this by Tullsen [9] and 
Vernet [10]. They have tried to translate an STG program directly into a Java 
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STG 




Fig. 1. A Two-Level Translation Scheme 



program. Since the STG is simply a functional language, it is the lower level 
implementation decisions that make the abstract machine spineless and tagless. 
Hence, in the direct translations, the issues in implementing the STGM are 
forced to blend with the ones in the representation with Java codes. Besides, both 
researchers describe their translation methods informally with several examples. 
For some thing, like tail recursion, it is not clear how they implemented it. 

In this study, we develop a two-level translation scheme: the first phase 
for compiling the STG language into an intermediate language called L-code 
(lambda code) and the second phase for representing the L-code language with 
the Java codes, as shown in Figure 1. The L-code is designed to specify precisely 
the behavior of STG programs with respect to the STGM. Each instruction of 
the language materializes explicitly the operations on closures, a register hie, a 
stack, or a heap, which may be derived from the intended meaning of the STG 
language, so it can be directly mapped onto some Java statements. A basic unit 
of L-code instuctions is clearly identihed in the structure of L-code programs, so 
it can be directly mapped onto exactly one class in Java. Every L-code program 
will reflect whole aspects necessary for the mapping. With this intermediate lan- 
guage, the translation issues can be separated from the representation ones, and 
each specihc matter can be concentrated on in a modular way. For each level, a 
concrete compilation rule is given, and it is perfectly reproducible. Based on this 
scheme, we have developed an LFL-to- Java compiler. For hve initial benchmarks, 
performance is very promising. 

The contributions of our study are as follows: 

— A systematic method of mapping the STGM onto arbitrary machines by the 
STG-to- L-code compiler and the reduction machine is provided (Section 2). 

— The representations necessary for the mapping from L-code to Java are de- 
termined, and an L-code-to-Java compiler is presented (Section 3 and 4). 

— The performance of the Java programs produced is measured (Section 5). 

After surveying related works in Section 6, we conclude in Section 7. 



2 The Spineless Tagless G-machine 

In this section, the STGM is described by four components: the STG language, 
the L-code, an STG-to-L-code compiler, and the L-machine. 
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2.1 Source Language 



The STGM treates the STG language as its source language. The syntax of our 
STG language is as follows: 



x,y,z,w 




variable 


V 


:= \x.e c X 


value 


e 


:= xqx\ let bind in e case e of Xz.alts 


expression 


b : 


:= V \ e 


bound expression 


7T : 


:= u \ n 


update flag 


bind 


:= x = b 


binding 


t 


:= c A default 


tag 


alts 


:= alt 


alternatives 


alt 


:= cT— >e default— >e 


alternative 


decl : 


• — T Cj Tli 


type declaration 


prg : 


:= decl, let bind in main 


program 



The notation obj^ denotes obji ... objn for n > 0. All bound expressions are 
syntactically divided into either weak head normal form (Whnf) v or non-Whnf 
e. Every binding has a update flag tt to determine whether the value of a non- 
Whnf is shared or not. In case expression, the ^ is a bound variable that is bound 
to some resulting value of its case scrutinee e. The symbol A as a tag over lambda 
abstractions is distinguished from constructor tags c, and the symbol default is 
considered as a special tag for convenience. An STG program consists of a let 
expression and type declarations that define tags and arities of constructors. The 
full detail can be found in Peyton Jones’s paper [7]. An example codelet is as 
follows: 

let s ^ \f g X. let a = g X va. f X a in ... 



2.2 Target Language 

The L-code is determined as the target language. The L-code is a kind of higher- 
order assembly language in which binding relationships in the source phrase are 
represented using those in the A-term, as introduced by Wand [12]. 
x,y,z,w,t,s register 

I label 

C ::= let ^ = C in C L-code 

I JMPCx jJMPKxyt | CASE t t->(/,xox) 

I GETN (Ax.C) I GETNT (Ax.At.C) | GETA (A(/,xox).C) 

I PUTARG X C I GETARG (Ax.C) | ARGCK n Qnp C 

I PUTK(/,x)C I GETK (A(i,x).C) | REEK (Ax.C) 

I SAVE (As.C) I DUMP C | RESTORE s C 

I PUTC x={l,x) C I GETC x (A(Z, w).C) | UPDC x (/, w) 

I PUTP (Z,x) (Ay.C) I STOP x 
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A register is an identifier used in L-code. A label I is uniquely given in let 
blocks for a sequence of L-code instructions. An L-code program for a given STG 
program will be a nested let expression. The meaning of each L-code instruction 
is precisely defined by the reduction machine shown in the next section. 

The purpose for the introduction of L-code is to identify explicitly every op- 
eration performed in the STGM by each instruction. This enables us to show 
our compiler with clearly set out compilation rules as will be shown. The com- 
plete specification using L-code for the STGM is also helpful to implement our 
compiler accurately because it specifies precisely how the STGM is to be imple- 
mented. The STG language itself has an operational reading so that it is not 
impossible to translate the STG language directly into Java, but the language 
leaves unspecified quite a few things for the implementation of the STGM. 

2.3 L-machine 

The L-machine is defined as a set of reduction rules for L-code as shown in 
Figure 2, and it uses runtime structures as follows: 



(l,p) closure 

p ::= X environment 

p, ::= po I ^[x I— > x] I ^[x 1] I p[t t] I p[s i— > s] register file 

s ::= So I s I (^) p) s stack 

h ::= ho \ h[x i— > {l,p)] \ h[l C] heap 



The reduction machine is pattern-driven; a reduction rule that matches the 
pattern of some current state is selected and applied. Usually, a state has the form 
ot C p s h. A register file ^ is a mapping of registers into addresses, labels, tags, 
or stacks. Note that an address is represented by a variable. An environment p is 
a sequence of addresses. A closure {I, p) consists of a label I and an environment 
p. A stack s is a sequence of addresses and closures. A heap is a mapping 
of addresses into closures and labels into L-codes. Here, po, So, and ho are an 
empty register file, stack, and heap respectively. 

In order to give readers intuition, we give a short informal explanation about 
the behavior of L-machine for each instruction: the JMPC x makes a tail call to 
the heap- allocated closure at the address stored in x. The JMPK x y t makes a 
tail call to the stack-allocated closure of the label stored in x, passing the address 
stored in y and a tag stored in t to the closure. The CASE tti^ (^i , xq Xi) selects 
a matching alternative of ti and jumps to the instructions of the label k, passing 
the addresses stored in xq and x^. The GETN, GETNT, and GETA receive the 
addresses passed by JMPC, JMPK, and CASE, respectively. The PUTARG inserts 
the addresses of some arguments at the top of a stack and the GETARG deletes 
them. The ARGCK n Cmp C checks the availablility of n arguments on stack. 
Then, it jumps to C if all n arguments are available, otherwise it jumps to Cmp 
in order to make a partial application. The PUTK, GETK, and REEK manipulate 
stack-allocated closures, while PUTC, GETC, UPDC, and PUTP work with heap- 
allocated closures. The SAVE, DUMP, and RESTORE control a stack, and the 
STOP X stops the reduction machine yielding an answer. 
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(let li = Ci in C) fj, s h 



=> C /j. s h[k I-+ Ci] 



(STOP x) n s h 
(JMPC x) ^j,s h 
(GETN (Ax.C)) X s h 
(JMPK y X t) s h 
(GETNT (Ax.At.G) xt s h 
(GASE t {li,xoXi)) n s h 

(GETA (A(Z,xox).C) {l,xox) s h 
(GETARG (Ax„.G)) (T„ s) h 

(PUTARG xC) II s h 
(ARGCK n Cmp C) {xm (l,p) s) 

(GETK (A(i,x).C)) p. i{l,x) s) h 
(PUTK {l,x) C) ps h 
(REFK (Ax.G)) p {{l,p} s) h 
(SAVE (As.C)) ps h 
(DUMP G) p {{l,p) s) h 
(RESTORE sC) p s h 
(GETG x (A(i,w).G)) ps h 



^ (a(^)i 
=> h{l) p{x) s h 
=> C po[xi-^ x] s h 

^ h{piy)) a(x) A(t) s h 
=> G /io [x t i-i tj s /i 
^ Wj) (^j,a(xo) A(x)j) s h 
(J>d^ m(xo) A(x)(i) s h 
=> G /io [xo xo , xTTlr] s h 
=> G /^[xH^Tr] s h 
^ C p {p{x) s) h 
C p (x m (l,p) s) h 
Cmp (2^771 (l,p) s) h 
=> G p[x i—>x]sh 
=> G 71 {{I, p{x)) s) h 
=> C p[x 1 ] {{I, p) s) h 
=> C p[s s] s h 
=> C p {I, p) h 
=> G /i p{s) h 
=> G /i[w w] s h 



(PUTC X = {l,w) C) p s h => G /i' s h[x* {I, p'{w))] 

(UPDG X {l,w) C) p s h ^ C p s h[p{x) 1-^ {I, /i(w))j 

(PUTP (Ay.G)) p {x^ {l',p) s) h 

=> G 7i[y y*\ {{I' , p) s) h[y* {Im+i, p{^o)xm)] 



e{x,l,pY 



if ^j.p{t) = tj 
otherwise^ 



if m > n 
otherwise 



9 {x, I, w) 

p' = p[x x*\^ 



n>m 



1. 9 {x,l,p) iff h{p{x)) = {I, p) where p and h are given on each context 

2. default^ (id, Xo Xd) is selected 

3. X* means a; is a fresh heap address 



Fig. 2. Reduction Rules of L-machine 



An example of reduction is shown below: 

(GETN (Az.GETC z (A(Z,, ).ARGCK 3 C„p C^))) z {f g x sq) h 
(GETG z (A(/s, )-ARGCK 3 C„ip C^)) 7io[z z] {f g x sq) h 
where h{z) = {Is,) 

(ARGCK 3 C„ip Cr) po[z z] {f g x sq) h 
where Cr = GETARG (Af g x.(let la — Cain Ci)) 

^ (GETARG (Af g x.(let la = Cain Ci))) [z^~^ z] {f g x sq) h 
(let la = Cain Cl) po[z ^ z,f ^ f,g^ g,x^ x] Sq h 
where Ci = PUTC a = (la,gx) (PUTARG x a C 2 ), C 2 = JMPC f 
(PUTC a^{la,gx) (PUTARG x a C 2 )) 7io[z x] sq h[la Ca] 

(PUTARG X a C 2 ) po[z 2 ;, ...,x ^ x,a ^ a] sq h[la ^ Ca, a ^ {la,gx)\ 
where a is a fresh heap address 

(JMPC f) 7io[z 2 , ...,x I— > x,a r-> a] {x a sq) h[la > Ca, a {la,gx)] 
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Eventually, the L-machine will produce an answer (x, h), if it exists, in which 
X is an address of some value and is a hnal status of the machine’s heap. 



2.4 Compiling STG Programs 

In order to compile STG programs, some auxiliary syntactic elements are needed: 
the partial applications {pap wq w), the indirection {ind w), the standard con- 
structors (c w), selection continuations {sel Xz.alts), the update continuation 
{upd Wi W 2 ), and the halt continuation (halt). 

Our STG compiler is presented in Figure 3. Notice that a set of free vari- 
ables in some syntactic element is annotated as a prefix of the element, such as 
{w}.Xx.e, for convenience; {7F„} is considered as {tci, ..., Such annotation 
is assumed to be calculated on the fly whenever needed. Notice also that symbol 
tables T are used in compilation rules. A symbol table r is a mapping of variables 
into registers. Similarly, tq is an empty symbol table. 

T ::= To I t[x x] symbol table 

As shown in Figure 3, our compiler is composed of five kinds of compilation 
rules: B for bound expressions, E for expressions, A for alternatives, C for con- 
tinuations, and X for some auxiliary expressions. The P rule receives an STG 
program and produces an L-code program in the form of nested let expressions 
that would be flattened by hoisting transformation. 

Note that, according to the compilation rules, all let-bound Cs are closed and 
may be hoisted out to the top level without difficulty. The hoisted version will 
form a single-level let expression, in which any let-bound C contains no other 
let expression. An example of compiling an STG program is shown below: 
let lupd — In 

let Is = Bl{}.Xf g xAet a A g X in f X a} n Is in ... 

— let lupd — In 

let Is = GETN (Az.GETC z {X{ls, ).ARGCK 3 (...)(GETARG (Af g x. 
let la = GETN (Az.GETC z (A(G, gx).SAVE (As.PUTK (Gpd.zs) 

(DUMP (PUTARG x (JMPC g)))))) 
in PUTC a = (G,gx) (PUTARG x a (JMPC f)))))) 

in ... 

From the above example, we get its hosisted version as follows: 
let lupd — ■ ■ ■ 

Is =GETN (Az.GETC z (A(i„)).ARGCK 3 (...)(GETARG (Af g x. 

PUTC a = (G,gx) (PUTARG x a (JMPC f)))))) 
la = GETN (Az.GETC z (A(G, gx).(SAVE (As.PUTK (Gpd,zs) 

(DUMP (PUTARG x (JMPC g))))))) 

in ... 

Let C be obtained from compiling an STG program. It will be reduced by 
applying the reduction rule =J>, starting from C po sq ho- 
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Bl{w}.\xn.el 7 T I =GETN (Az.GETC z (A{/, w).ARGGK n 

(PUTP {lpap.i,z}^ (Ap.REFK (Ay.JMPK y p A))) 
(GETARG (Ax.-E[e] ro [w w, a; x])))) 

-B[{w}.ctiJ] n I =X[{l 7 i}.c«}] I 

B[{w}.e] u I =GETN (Az.GETC z (A(Z,w).SAVE (As.PUTK {Lpd,zs) 

(DUMP {Elej ro[ w^ w ]))))) 

n I =GETN (Az.GETC z (A(Z, w).£'[e] to[w i-> w])) 

E[xo x\t = PUTARG 7 ^ (JMPC r(xo)) 

S[casee of {TJ}. Ax. a/is] t= let Isei = Cl{w}.sel Xx.alts} hei 

in PUTK (Z,eZ, 7 H> (EM r) 
where hei fresh 

S[let Xi = {Wi}.bi in e] r = let k = m U {h^cy) 

in PUTC Xi = (Zi,Wi) [E\e\ r[xi ^ Xi]) 
where U = lc and vji = r[xi Xi](j/) if bi = cy 

li fresh and Wi = r[xi Xi](ui) otherwise 

yl|{«J}.c x^e] I =GETA (A(Z, z w).GETC z (A(t,x).i?[e] to[vj xh^x])) 

yl|{«J}.default^ e] I =GETA (A(Z, z w).i?[e] ro[w i-> w]) 

Cl{wi,W2}.upd wi W2] I = Xl{wi,W2}.upd wi W2] I 
Cl{w}.sel Xwo-altij I =let k = yl|aZti| k 

in GETNT(Awo.At.GETK(A(Z,w).CASEtti^(Zi,woWi))) 
where k fresh, alU = {wi}.U...-^ ... 

Cl{}.haltj I =Xl{}.haltj I 

Xl{wo,w}.pap wo TJ] I =GETN (Az.GETC z (A(Z, wo w). PUTARG w (JMPC wq))) 
Xl{w}.ind w] I =GETN (Az.GETC z (A(Z,w).JMPC w)) 

X|{«J}.c w] I = GETN (Az.REFK (Ax.JMPK x z c)) 

Xl{wi,W 2 }.upd wi W2I Z = GETNT (Az.At.GETK (A(Z,wiW2). 

RESTORE W2 (UPDC wi (Zw,z) (JMPC z)))) 
Xl{}.haltj I =GETNT (Az.At.GETK (A(/,).STOP z)) 

P|decZ,e] =letZ pap,m — Xl{W m} -P(^P ^mj lpap,m (m > 1) 

^ind ~ mj lind 

lupd = Xl{wi,W2}.upd Wl 102] lupd 
halt = X{{}.halt\ halt 

Ic = Xl{wn}.c «J„]] h (T En e decl) 
in PUTK {Ihaiu) {E\e} tq) 



Fig. 3. Compilation Rules for the STG Language 



3 Representation 



From now on, we will concentrate on the development of an L-code-to-Java 
compiler. In this section, the method with which the elements in the L-machine 
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is represented in Java language is explained. In the next section, the compiler is 
defined, based on the representations. 



3.1 Closure 

The class Clo is a base class that captures common elements among closures. 
It has a public member variable ind that is initialized to itself, and an abstract 
member function code(). 

public abstract class Clo { 
public Clo ind — this; 
public abstract Clo code{); 

} 

Every closure, e.g. of label I, is represented by a class that extends the base 
class by adding some member variables as its free variables and overriding the 
code() of the base class as follows: 

public class Cj extends Clo { 
public Object fi, ... , 4; 
public Clo code() { ... } 

} 

Note that member variables are declared as type Object, which is the super- 
class of all classes in Java. Whenever items specific to some inherited class, such 
as accessing member variables in the class, are needed, the Object class can be 
cast into an appropriate class in our compilation scheme. 



3.2 Runtime System 

Our runtime system is a class G that equips static variables node, tag, loopRag, 
sp, bp, and stk. 

public class G { 

public static Object node; 
public static int tag; 
public static boolean loopHag; 

public static int sp, bp; 
public static Object\\ stk; 

} 

The node variable G.node and the tag variable G.tag are used for passing 
the address a: of a heap-allocated closure and the tag t respectively, as shown in 
the reduction rule: 



(GETNT (Ax.At.C)) x t s h ^ C po[x x,t t] s h 
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A register file does not require any gadgets. Instead, the mapping by the register 
file is simply resolved by the scope rule in Java languages. A stack is repre- 
sented by a big array G.stk of type Object, and G.sp and G.bp point to the 
top and bottom elements of the top portion of the stack respectively. A heap is 
represented by the internal heap provided by the JVM. 

Note that the stack represented by an array has to be carefully handled. First, 
after an object is deleted from the top of a stack, the deleted entry of the object 
must be filled with null in order to inform the JVM that the object in the entry 
may be unnecessary. Second, an array of type Object can contain only values 
of any classes (or reference data type [3]), but the insertion of primitive values 
of types such as int and boolean will cause type violation at compile-time. This 
prevents the passing of unboxed arguments that are represented by primitive 
values. Instead, we pass them through global registers which are represented by 
static variables of appropriate primitive types. 

3.3 Updating 

In conventional machines, updating is achieved by directly overwriting a value 
at a given address. However, the JVM provides no way to construct one object 
directly on top of another. Therefore, updates must be managed in an alternative 
way. To do this, a special class Ind is introduced. 

public class Ind extends Glo { 

public Glo codeQ { return this. ind; } 

} 

Whenever any non-Whnf is allocated, an object of Ind class is created to- 
gether and its ind field is set to point to the non-Whnf. Later, at the time the 
non-Whnf is updated with a value, the ind field is given the value. Refer to the 
compilation rule for PUTC and UPDC in Section 4. 

Note that every object representing a thunk is reachable only through an 
additional indirection object of the class Ind in this implementation. This indi- 
rection cannot be easily removed if a garbage collector does not treat it specially 
as in the conventional implementations. Although it is not possible to build up a 
chain of indirections in this implementation, even one-lengthed chains may cause 
a space leak. Probably, all the approaches in compiling lazy functional languages 
for the JVM are expected to suffer from this problem since it is not possible to 
interact with the built-in garbage collector of the JVM in general. 



3.4 Tail Call 

The STGM mostly transfers control in tail calls. Every tail call can be imple- 
mented by a single jump instruction on conventional machines. Since no tail call 
instruction is provided in the JVM, they must be simulated by a tiny interpreter 
as follows: 



public static void loop (Glo c) { while (foopflag) c = c. ind. codeQ; } 
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Every sequence of L-code instructions ends with one of JMPK, JMPC, and 
CASE, according to our compilation rule shown in Figure 3. The three instruc- 
tions are translated into Java statements that return an object to which control 
is transferred. After the return, control will reach the assignment statement in 
the body of the while loop of the above interpreter, and the interpreter will 
call the object’s code() if loopBag is true. Here, the loopBag is a static boolean 
variable to make the STGM go or stop. 

4 Compilation 

Our compiler receives a hoisted version of L-code program, and generates Java 
classes using compilation rules for L-code instructions shown in Figure 4. Ba- 
sically, our compilation scheme considers each closure as one class, which has 
member variables as the closure’s free variables and has one method that simu- 
lates the closure’s instructions. 

Recall that a hoisted version of L-code program forms a single-level let ex- 
pression containing let bindings I = C. By hoisting transformation, each C con- 
tains no inner let expression. Hence, a simple driver is needed to generate a class 
for each binding. 

The driver may introduce member variables of the class from the relevant 
free variables obtained by analyzing the C. For convenience’s sake, the STG-to- 
L-code compiler is assumed to annotate them to the binding like I — {ly}.C, so 
the driver will use the annotation to make the member variables. The body of 
code() in the class will be filled with the Java statements generated by applying 
our L-code-to-Java compiler to the C in the binding. 

Our compiler neatly maps registers used in L-code into some variables in Java 
codes. Each register will be accessed by its name, rather than by some offset as 
in conventional implementations. Accessing variables by names is much better, 
as it does not require costly array accesses. 

In general, for bound variables x in some L-code ... (Ax. ...), local variables x 
of type Object are declared in J rules. Sometimes, it is not necessary to declare 
such local variables, for example, as in the rule for GETA. The reason is that the 
required local variables are already declared. According to the rule for CASE, 
Java codes generated from this instruction are combined with those generated 
from alternatives, though they are not in the same closure in terms of L-code. 
Since free variables that occur in the alternatives must be declared in the closure 
in which the CASE resides, the free variables in the alternative can be accessed 
from the preceding declaration by the scope rule in Java language without any 
additional declaration as in GETA. 

For SAVE and RESTORE, the base pointer G.bp is stored and restored instead 
of an entire stack, which is a well-known technique explained by Peyton Jones 
[7]. Note that, in the case of SAVE (As.C), J declares a variable s of type int as 
the bound variable s because it will hold the value of G.bp. 

Due to space limitations, we omit discussion of some details of the L-code-to- 
Java compiler, including unboxed values and primitives. We also omit discussion 
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J|JMPC x] = G.node = x; return (CIo)x 

J|JMPK X y t] = G.node = y; G.tag = t; return (CJo)x 

J|GETN (Ax.C)] = Object x=G.node; J[C] 

JfGETNT (Ax.At.C)l = Object x= G. node; int t=G. tag; JIICl] 

J|GETA (A(i,xw).C)I = J[C] 

J[PUTARG x„ C| = push Xi,; ... push xi; J|C]] 

J[GETARG (Ax„.C)] = Object xi,...,Xn; pop xi; ... pop xy, J|C] 

J|PUTK (i,x„) C)] = Cl o = new CiQ; o.fi=xi; ... o.£i = Xn; push o; J|C] 

where o fresh 

J|GETK A(l,x„).C)] = Objecto; pop o; 

Object XI = ((Ci)o).fi, ... ,Xn = ((Ci)o).fn; J|C] 
where o fresh 

J[REFK (Ax.C)] = Object x=G.stk[G.sp]; Jiq 

J|SAVE (As.C)] = int s=G.bp; J[C| 

J|DUMP C] = G.bp=G.sp; J[C] 

J[REST ORE s C] = G.bp = s; J[C| 

J[PUTC Xi = (li,w) ) C] = ... alloa; ... assign];... J[C] 

J mj ^ 



where alloci = Cj,. Xi = new Gjj() 


if TTi = n 


= Ind Xi = new IndQ; 


if TTi = M 


Xj.ind = new Gjj() 




assign] = Xi.fj = wj 


if TVi = n 


= ((Ci^)xi.Jnd).fj = Wj 


if TTi=U 



J[GETC y (A(i,x„).C)] = Object xi = ((C,)y).fi; ...;x„ = ((G)y).f„; J[C] 

J[UPDC x {l,Wn) C] = Cl o = new G(); o.fi = wi; ... o.fn = Wn; 

{{Clo)x).ind = o; J[C] where o fresh 
J|PUTP (h,y)„) (Ax.C)] = switch(G.sp— G.bp) { 

case 0 : Gg x = new Cg(); x.fr=y; break; ... 
case n— 1 : Cg x = new Gg(); x.fi=j; 

pop x.f 2 ; ... pop x.fii; break; 

^ } m 

J|CASE t Ci^(h,xoXi) default^ (id, xoXd)] 

= switch(t) { ... case q : J|CjJ ... default : J[Cjj]} 
J|ARGCK n Ci C 2 )] = if(n > G.sp—G.bp) then { J[Ci] } else { J[C 2 ] } 

J[STOP y] = G.Joophag = false; return null; 

push X = G.SP++; G.stk[G.sp] =X 

pop X = G.sp — ; X = G.stk[G.sp+l]; G.stk[G.sp+l] =null 

Fig. 4. Compilation Rules for L-code 



of the known-call optimization to pass arguments via some agreed static variables 
rather than via the costly stack. 

An example of compiling the L-code instructions bound to la presented in 
Section 2.4 will be shown as follows. This example shows well the relationship 
that a let binding is directly translated into one Java class. Since our STG- 
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to-L-code compiler expresses each closure with a let binding, this example also 
shows the direct relationship between a closure and a class. 



public class extends Clo { 


//la = 


public Object fi, 


// {9: 4- 


public Clo code{) { 




Object z = G.node; 


// GETN Az. 


Object g = ((CjJz).fi; 


// GETC A(G,gx) 


Object X = ((CjJz).f 2 ; 




int s = G.bp; 


// SAVE As. 


Ci.pd 0 = new 


// PUTK {l^pd,zs 


o.fi = z; o.f 2 = s; 




G.sp -H-; G.stk[G.sp] = o; 




G.bp = G.sp; 


// DUMP 


G.sp -H-; G.stk[G.sp] = x; 


// PUTARG X 


return {Clo)g; 


// JMPCg 



5 Benchmarking 

We experiment with five small Haskell programs that have been used by Mee- 
han and Joy [5]: fib 30, edigits 250, prime 500, soda, and queen 8. A SUN 
UltraSPARC-II workstation with a 296MHz processor, 768Mbytes of memory 
and Solaris version 2.5.1 is used. For compilers, GHC 4.04, Hugs98 Feb-2000, 
and Sun JIT compiler version 1.2.2 are used. To obtain optimized versions of 
STG programs, GHC are executed with -02 option. 



5.1 STG-Level Optimizations 

One of advantages in using the STGM is that many STG-level optimizations in 
GHC can be exploited freely. Ideally, our implementation can be imagined as a 
back end of GHC. In our prototype, our own STG-like functional language is 
defined, showing that the language is capable of precisely expressing the opera- 
tional behaviors of the STG language in terms of the STGM. We extracted STG 
programs by running GHC with the option -ddump-stg from our Haskell bench- 
marks. Then the STG programs are semi-automatically modified according to 
the syntax of our own STG-like language. The main reason for the modification is 
that our implementation covers only a part of the libraries implemented in GHC. 
This translation is quite straightforward. Then, the modified STG programs are 
compiled into Java programs according to our compilation rules. 



5.2 Results 

Table 1 compares code sizes in bytes. For GHC, the sizes express the dynamically- 
linked executables stripped of redundant symbol table information. For Hugs, no 
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Table 1. Code Sizes in Bytes 



Pgms 


GHC 


JITiunopt 


JIT:opt 


fib 


268,028 


24,830 (037 classes) 


18,610 (034 classes) 


edigits 


283,092 


113,913 (135 classes) 


64,327 (092 classes^ 


prime 


280,248 


74,161 (096 classes) 


50,025 (070 classes] 


queen 


274,816 


108,705 (134 classes) 


75,619 (101 classes] 


soda 


302,972 


335,873 (388 classes) 


185,496 (203 classes] 



sizes are given, as compiled codes exist only within the develpment environment. 
For our compiler, the sizes are obtained by summing up the sizes of class files 
produced from each program itself and the runtime system. The number in each 
parenthesis is the number of classes. Note that our runtime system consists of 4 
classes with 2972 bytes. 

Table 2 compares execution times in seconds. Each entry is the sum of user 
time and system time. The execution time is measured by UNIX time command; 
each benchmark is run five times and the shortest execution time is chosen. For 
Hugs, each execution time is calculated by a timer supported in Hugs and it 
excludes the time on parsing, type checking, and G-code generation. 



5.3 Discussion 

According to Table 1, each program consists of relatively many classes, since one 
class is generated for each closure. Particularly, the size of the unoptimized soda 
program is larger than that of the binary soda program generated by GHC, which 
stems from generating more updatable expressions by the naive translation of 
the string lists. As Wakeling did in his JFP paper [11], we can similarly reduce 
the bytecode size of generated classes by merging classes that have the same 
types of fields. By modifying only the L-code-to-Java compiler, we can cut the 
bytecode size by half and the number of classes is reduced to about 20 in all 
benchmarks. 

According to Table 2, the execution times of generated Java programs lie 
between those of the relevant programs by GHG and Hugs. First, it is not sur- 
prising that the generated Java programs are slower than binary executables by 
GHG. The JVM is known to make memory allocation more costly, it ignores 
strong typedness of the Haskell programs so that it repeats unnecessary runtime 
checks, every tail call must be simulated by a return and a call instead of a single 
jump instruction, and the simulated stack incurs unnecessary cost for checking 
array out-of-bound index and assigning null after a pop. 

Second, the generated Java programs tend to outperform the execution times 
in Hugs, particularly when GHG’s STG-level optimizations are applied; in that 
case, all programs except soda run faster. In the case of soda, because the 
warming-up time of the JVM varies from 0.68 to 0.74 seconds, any generated 
Java program for soda cannot run faster than in Hugs. By refining the way 
of interaction between a primitive and a case expression in the STG-to-L-code 
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Table 2. Execution Time in Seconds 



Programs 


GHC 


Hugs 


JITmnopt 


JIT:opt 


fib 


0.18s 


106.48s 


25.70s 


5.72s 


edigits 


0.16s 


3.10s 


9.15s 


2.42s 


prime 


0.14s 


3.30s 


86.38s 


1.97s 


queen 


0.07s 


5.79s 


5.35s 


2.29s 


soda 


0.03s 


0.41s 


2.26s 


1.59s 



compiler, all the above execution times can be cut down to a half, on average. 
These results show that our systematic compiler also generates Java programs 
which run at a reasonable execution speed. 

The STG-level optimizations by GHC dominantly affect the execution times 
of all programs. In the case of prime, they are particularly effective. Its explana- 
tion may be given in the aspect of total heap allocation since execution time is 
usually affected by the amount of heap allocation in lazy functional languages. 
An optimized version of prime allocates 35,061,856 bytes, while unoptimized ver- 
sion allocates 2,603,827,792 bytes. The unoptimized prime allocated 74.3 times 
more heap objects than in its optimized version. By this observation, we notice 
that more reduction in heap allocation tends to affect more reduction in execu- 
tion time. This is a reasonable expectation as in conventional implementations, 
and we believe this is also true for the implementations on the JVM, particu- 
larly because the cost of memory allocation is known to be more expensive in 
the JVM than in the conventional machines. 

6 Related Works 

The previous works based on the STGM are Tullsen [9] and Vernet [10]. As 
done in the original paper regarding the STGM [7] , both papers explained their 
own mapping informally based on examples. With these descriptions, we cannot 
reproduce their compilers. Furthermore, we cannot compare the performance, 
since no experimental result for performance is provided. 

Other works are based on either G-machine or {v, G)-machine. Wakeling’s 
compiler [11] has two distinct features. It employs a list of small local stacks 
instead of one single big stack, which comes from a feature of {v, G)-machine, and 
it also generates much smaller number of classes over quite big benchmarks by 
efficient representations. The generated Java programs run at competitive speed 
with Hugs. Wakeling explained that the size of class files affects performance. 
Although we didn’t compare our compiler with his in terms of performance, 
our compiler based on the STGM is believed to be advantageous in that it can 
exploit STG-level optimizations as well as his idea on the efficient representations 
to reduce the size of class files. Further work is required. 

Meehan and Joy’s compiler [5] represents functions by methods in a single 
class and uses the Java reflection package to access the methods. Their generated 
Java programs by the compiler runs slower than with Hugs. 




106 K. Choi, H.-I. Lim, and T. Han 



Recently, we heard that Erik Meijer, Nigel Perry, and Andy Gill are working 
on a Java back end for GHC, though no documentation is available for their 
work [6]. 

Some research has been done on compiling strict functional languages for 
the JVM. Benton, Kennedy, and Russel have taken with Standard ML(SML) as 
their source language, improving performance through extensive optimizations 
and providing SML with an interface to Java [1][2]. Their approach is similar to 
ours with Haskell. 

7 Conclusion and Further Works 

In this study, a systematic specification of the STGM is presented by defining 
our STG-to-L-code compiler and L-machine. It is a new attempt to describe 
the mapping accurately by the provision of concrete compilation rules. It is 
compact enough to be presented in a few pages, but exposes every aspect for 
the mapping of the STGM. Each instruction of L-code is directly mapped onto 
some Java statements, and each let binding identifies all the instructions within 
one closure so that the closure is nicely mapped onto one class in Java. 

Based on the specification, a concrete compilation rule for the JVM is defined. 
In this phase, the goal of implementing the STGM is decomposed into the sub- 
goals of implementing L-code instructions. We have defined an L-code-to-Java 
compiler with our representation decisions. 

Since our approach is based on the STGM, the generated Java programs 
are indirectly amenable to the STG-level optimizations in GHC. The initial 
performance is measured with five small Haskell benchmarks. Combining the 
optimizations, promising results are obtained for the benchmarks. 

As a further work, we hope to devise more ingenious Java representation; 
our representation scheme is a bit straightforward. Also, it is important to apply 
our compiler to bigger benchmarks, and this will give more decisive figures for 
performance of the translated Java programs. Finally, we hope to more fully 
exploit the features of the two-level translation; one may analyze flow information 
in terms of L-code to optimize L-code programs, and one may devise Java-related 
optimizations relevant to our compilation scheme. Each work could be done 
separately. 
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Abstract. We present a framework for the combination of Constraint 
Logic Programming ( CLP) and higher-order Hereditary Harrop Formulas 
{hoHLL). Our aim is to improve the expressiveness of traditional Logic 
Programming with the benefits of both fields: CLP and hoHH. The result 
is denoted higher-order Hereditary Harrop Formulas with Constraints 
{hoHH{C)). The syntax of hoHH is introduced using lambda-terms and 
is enriched with a basic constraint system. Then an intuitionistic sequent 
calculus is defined for this combined logic, that preserves the property 
of an abstract logic programming language. In addition, a sound and 
complete procedure for goal solving is presented as a transformation 
system that explains the operational semantics. 



1 Introduction 

Expressiveness is a valuable help for the user of a programming language. Con- 
straint Logic Programming (CLP) [4] and Hereditary Harrop Formulas (HH) [9] 
are two different extensions of Logic Programming (LP) increasing the expres- 
sive capacity of this kind of programming in two new signihcant ways. Namely, 
CLP enriches LP with the aptitude to obtain declarative programs over different 
computation domains in which the constraints are interpreted, while HH offers 
a broader deduction system in which the declarative meaning of a program is 
operationally interpreted. 

On the other way functional programming languages involve a substantial 
increment of expressiveness permitting the treatment of programs as data. This 
idea of higher-order programming has been also developed within the logic pro- 
gramming. For instance. Miller et al. [8] elaborated higher-order logic program- 
ming by utilizing higher-order horn clauses and HH. It is also well known that 
programming languages based on higher-order logic support some additional 
abilities like meta-programming, and theorem proving tasks. In particular, there 
are several examples of the use of A-Prolog -based on higher-order HH- from 
the perspective of meta-language, [10,2]. 

In [5] a framework for the combination of CLP and HH approaches was in- 
troduced, improving the syntax of Rrst-order HH with constraints belonging to 
a given constraint system C, obtaining a scheme HH(X) with instances HH(C). 
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This combination makes it possible for the user to transcend the lack of expres- 
siveness of Horn clauses, limited to the boundaries of the Herbrand universe. 

The aim of this paper is to incorporate higher-order to HH{C) in order to 
improve the capabilities of the language introduced in [5] with the expressiveness 
and abstraction of higher-order. The higher-order extension presented {hoHH{C)) 
is based on the Church’s formulation of Simple Theory of types, which permits 
the use of A-terms as a tool for representing and manipulating both functions 
and predicates as data. An intuitionistic sequent calculus is dehned, resulting in 
a constructive inference mechanism to deduce goals from program clauses. So we 
obtain a higher-order language with constraints that preserves the property of 
an abstract logic programming language in the sense of [8]. In addition, a sound 
and complete procedure for goal solving is presented as a transformation system 
that explains the operational semantics. As in CLP , the result of solving a goal 
using a program will be an answer constraint. 

The following example (written with a sugared notation) belongs to the in- 
stance hoHH{TZ) given by a constraint system for real numbers in the higher- 
order context. Let Ai be a program with dehnitions of geometrical hgures of the 
plane by means of dehnite clauses: 

Ai = K, 1 ^ circlel[x, y)), 

« 2 =y circle2{x, y)), 

+ 6j/^ « 2 =y ellipse{x, t/))}. 

Now we may introduce atoms expressing that circlel, circlc2 and ellipse are 
hgures: 

A 2 = {fig(circlel), fig(circle2), fig(ellipse)}. 

Suppose we may wish to know, for a provided database of dehned geometrical 
hgures of the plane, the intersection points of a pair of hgures. For the program 
Ai U A 2 , this problem has a higher-order formulation: 

G = 3 C\ 3 C 2 {fig{C\) Afig{C2) A C\ ^ C2 A C\{x,y) A C2{x,y)). 

Note that, for instance, the constraint C\ rfe C'2, expressing that the two 
predicate variables C\, C'2 are not equal, can not be expressed in A-Prolog. 

A more general approach could be to dehne the property intersection that is 
verihed by the binary relations which relate x and y if (x,y) is a point in two 
different hgures: 

zis = {^CiWC2{fig{Ci)Afig{C2) AC'i^C'2^ 

inter section[\x ,\y .[C\{x , y) A C* 2 (*, t/))))}. 

For the program A = Ai U A2 U As, the preceding goal can be expressed 



by G = 3T [inter section[T) AT[x,y)). Then one of the possible answers is the 
constraint: R = x ^ 

If we modify the program Ai: 

A[ = {'ix'iy[x^ y"^ < I ^ circlel[x, y)), 

3- C‘2 =y circle2[x, y)), 

+ 6j/^ < 2 =y ellipse[x, j/))}. 



the goal: 



G' = V*Vt/(*2 + j/2 < 2 ^ fig[G) A G[x, y)) 



searches hgures contained in circle2. There are three possible constraint answers: 



= G « circlel, R 2 = C ps circle2, Rs = G ^ ellipse. 
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The rest of this paper is organized as follows: In Section 2 we recall the notion 
of a constraint system and we dehne the syntax of a general higher-order logic 
with constraints, for which an intuitionistic sequent calculus is introduced. In 
Section 3 we restrict the logic to the higher-order Hereditary Harrop Formulas. 
Then, in Section 4 we present a new calculus that only allows uniform proofs. 
For the new logic, this proof system is equivalent to that presented in Section 2. 
Based on this second calculus, a sound and complete procedure for goal solving 
is presented as a transformation system in Section 5. We hnish developing some 
application examples in Section 6, and summarizing conclusions and possible 
lines for future research, in Section 7. 

2 Higher-Order Formulas with Constraints 

The syntax of the higher-order logic we present is based on the typed A-calculus. 
The main components of this language are the terms and the types. Types are 
built up from a set S of sorts s, that contains a special sort for formulas o, and 
a set TC of type constructors ct. The set of types, with elements denoted r, is 
dehned by the following syntactic rules: r := s | ct(ri, . . . , r„) \ t\ T2- The 
functional type associates to the right. 

Terms are obtained from a set V of typed variables, x : r, and a signature 
S that is a set of typed constant symbols, c:r, by abstraction and application 
operations of the A-calculus. V and S are implicitly related to S and TC, but 
in order to simplify the notation, we do not note this explicitly. The set of 
terms Ts{V) (or simply T), with elements denoted t, is dehned by the following 
syntactic rules: t :=x:t |c:r \{Xx:T.t) \ (CC)- We omit parenthesis when they 
are not necessary, assuming that abstraction and application are right and left 
associative, respectively, and that application has smaller scope than abstraction. 

If t is of type T 2 , then Xx'.Ti.t is of type t\ — t T 2 . If t\ is of type t\ T 2 and 
t2 is of type ri then ti t2 is of type T2- We remove the type mark of variables 
and constant symbols when it is not relevant. Instead, when it is needed to state 
explicitly the type of a term, we write t : t to express that the type of t is r. 
Terms of type o are called formulas, and they are usually denoted by F . 

We will assume that S is partitioned into nonlogical constants and logical 
constants. The latter comprises the following typed symbols T :o, T:o (repre- 
senting true and false, resp.), A:o— ^o— ^o, V:o— ^o— ^o, =y: o — ^ o — ^ o, 
and for each type r, 3 : (r — ;> o) — ;> o, V : (r — ;> o) — ^ o. We use inhx notation for 
A, V, =>, and we abbreviate 3{Xx.F), V(A*.T) by 3xF and tfxF, respectively. 
We simplify -iF for T =y T. We call a formula whose leftmost non-parenthesis 
symbol is either a nonlogical constant or a variable atomic formula, rigid for the 
former case, and flexible for the latter. The symbol is called predicate symbol and 
predicate variable, respectively. 

The concepts of free and bound variables of a term, and the substitution 
of a free variable by a term are dehned as usual in the A-calculus. We use the 
notation Freeft) or Free(S) to denote the set of free variables in a term t or in 
a set S, respectively; t is closed if Freeft) = 0. We denote by a substitutions of 
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the form \ti/xi, . . and ter or Scr the application of a substitution cr to 

a term t or to every term of a set S, respectively. 

We adopt the usual a, /3, ?y-conversion rules of the A-calculus, that in fact 
determine an equivalence relation =af 3 r] between terms. We say that a term is 
in X-normal form, when it is in both {3, ?y-normal form. We denote by A[t) the 
A-normal form of the term t. 

In order to distinguish formulas that are constraints, we assume that the 
predicate symbols of the nonlogical part of S are divided into dehnite and in- 
dehnite predicates. The indehnite predicate symbols are used by the constraint 
system. We assume also that for every type r, there is an indehnite predicate 
symbol r — ;> r — ;> o, to represent the equality relation, that we will use in 
inhx notation. 

Following [12], we view a constraint system as a pair C = {Cc,'^c), where 
Cc is the set of formulas in A-normal form allowed as constraints, and \~c C 
V{Cc) X Cc is an entmlment relation. We use F for a hnite set of constraints. 
r \~c C means that C is entailed by F . We write just he C if is empty. We 
will say that a constraint C with Free{C) = {xi, . . . , x„} is C-satishable when 
\~c 3*1 . . ,3x„C. C is required to satisfy certain minimal assumptions, mainly 
related to a, {3, ?y-conversion in A-calculus, the equality relation, and to the logical 
constant symbols. We assume that: 

— Every hrst-order formula in A-form built using indehnite predicate symbols, 
and the logical constants A, =>, 3 and V is in Cc- 

— All equations t\ « ^2 are in Cc- 

— All the inference rules related to A, =>, 3, V and « valid in the intuitionistic 
logic with equality are valid to infer entailments in the sense of he (see e.g. 
[11])-' 

— T he C implies Ter he Ccr for every substitution cr. 

If t\ then he t\ re> T. 

Note that these conditions must be considered as sufficient for a system to be a 
constraint system. In this way, the equality relation is always included, but the 
system can include other relations like < -see the example of the Introduction- 
or additional connectives like V. Note also that Cc is restricted to hrst-order for- 
mulas, except for equations that in general are used to represent substitutions or 
a, /3, ?y-equivalence. This hrst-order condition could be eliminated, but then the 
constraint system will become unjustihably hard for implementation. In practice, 
usual constraints (other than equations) belong to a hrst-order language. 

Two examples of valid constraint systems are: %, where h^ is the entailment 
relation of classical logic modulo Clark’s axiomatization of the Herbrand universe 
[1], with equality and a, {3, ?y-equivalence between terms. TZ, where the entailment 
relation 'r-n is similar to the example before, but modulo Tarski’s axiomatization 
of the real numbers [13]. In these cases, the hrst-order part of the the constraint 
system is known to be effective, in the sense that the validity of entailments 

^ We note that regarding equality between predicates, the axiom of extensionality is 
not assumed. 
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r \~c C , with finite F , can be decided by an effective procedure. This procedure 
should incorporate special tasks to solve equations. 

2.1 A Proof System 

We present an intuitionistic sequent calculus for higher-order formulas with con- 
straints, called hole that works with sequents of the form 0 | — F , where 0 is a 
hnite set of formulas in A-normal form, and T is a formula in A-normal form. It 
combines the usual inference rules from intuitionistic logic with the entailment 
relation \~c of a constraint system C. hoIC stands for a higher-order Intuitionistic 
sequent calculus that handles Constraints. 0 \~hoic F if and only if the sequent 
0 I — F has a proof using the rules of the system hoIC that we introduce in the 
following. A proof of a sequent is a tree whose root is the sequent and whose 
leaves match axioms of the calculus. The rules regulate relationship between 
child and parent nodes. We will simplify 0U{T} by 0, F , and we will represent 
by F the set of constraints contained in the set 0. 

Rules to deal with (rigid or flexible) atomic formulas or constraints: 

— — — — {Atomr) F, F' atomic, F' rigid, F \~c F ^ F' . 

0, L |— L 



0\^F 



(Atomf), where A a predicate variable, F \~c X ^t, 



0 I Xti . . .tr. 

Free{t) C Free{{ti,. . .,t„}),T = A{{Xti . . .t„)[t/A]). 



0H0 

Rule concerning contradiction: 



(Cr), if 0 is a constraint and F \~c C. 



0^F 

Rules introducing connectives and guantifiers: 

0,F,^F 0,F,^F 

0,FiWF2^F ^ 

0,F,,F2^F 
0,01 A 02 H0 ^ 

0H01 0,02^0 . ' ^ 

0,01^02^0 ^ 



0^01 V02 

0H01 0H02 ^ 

0H0iA02 ^ 

0,01 H02 , . ^ 

10 



0,0i[i//lH0 



(1 



0,C'^F[y/x] 



0H01 



(3/{), C a constraint, F \~c ^yC. 



0,3xFi\-F 0'^3xF 

In both rules, y does not appear free in the sequent of the conclusion. 
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0,F,[y/x],C^F 
0,'ixFi \-F 



(Vi), C a constraint, F \~c ^yC. 



<9 \—F[y/x] 
0 \-\fxF 



(V_r) 



In both rules, y does not appear free in the sequent of the conclusion. 



In the rules dealing with atomic formulas, and in those introducing a connec- 
tive, the involved atomic formulas, and the formulas containing the introduced 
connectives, respectively, are not a constraint. 

The structural rules contraction and interchange, common in this kind of 
calculus are not necessary here, because 0 is taken to be a set, not a list. This 
calculus is similar to those dehned for higher-order formulas in the literature 
(see e.g. [8]), but the presence of constraints induces some modihcations. There 
are not rules for -i, since the notion of negation may be provided replacing ~<F 
by T =y T. T can be considered as a constraint that could be deduced with 
{Cr) if there are inconsistent premises. The rule (A), that transforms formulas 
by A-conversion, is not dehned in hoIC because assuming that formulas in the 
initial sequent are in A-normal form, every formula in a sequent of a proof is 
also in A-normal form. Note that no substitution of a term by a variable is made 
during the application of the rules, except in (Atomf), where A-normal form of 
the consequent is required. 

The motivation for rules (3/{) and (Vi) appears in [5], they include the fact 
that substitutions can be simulated by equality constraints, and at the same 
time, they rehect the possibility of hnding a proof for an existentially quantihed 
formula, knowing a property (represented as a constraint) of the instance of the 
existential quantihed variable. 

The rule [Atonrir) corresponds with the usual dehnition of initial sequent, 
but adding the power of the constraint system. For instance: 



annoyed(john) , annoyed fa irritated\ — irritated(john) ’’ 

because: annoyed ^ irritated \~c annoyed(john) « irritated (john). 

The rule (Atomf) is needed due to the facts that substitutions are not per- 
formed in the rules for quantihers, and that in higher-order logic, replacing a 
predicate variable by a term not necessarily preserves the atomic structure. Let 
us see an example using the notation of the Introduction. 



T 



\x.\y. (circle l(x, y) A ellipse(x, y)) \ — circlel(x, y) A ellipse(x, y) 
T « Xx.Xy.( circle l(x, y) A ellipse(x, y)) \ — T(x, y) 
\^3T(T(x,y)) 



(Atomf) 

i^R) 



because: \~c 3F(T « Xx.Xy. (circle l(x,y) A ellipse(x,y))), and 

A(T(x, y)[Xx. Xy.( circle l(x,y) A ellipse(x , y)) /T]) = circlel(x,y) A ellipse(x,y). 
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3 Higher-Order Hereditary Harrop Formulas with 
Constraints 

In order to obtain a language that preserves the property of goal-oriented search 
for solution, common in Logic Programming, we will restrict the logic to higher- 
order Hereditary Harrop Formulas (shortly, hoHH). The atomic formulas of 
hoHH use dehnite predicate symbols, and are limited to be positive in accordance 
with the following dehnition. 

Definition 1 Given a signature S and a set of variables V, the set of positive 
terms VT i]{V) (simplified VT ) consists of all the terms in X-normal form not 
containing indefinite predicate symbols, nor the logical constants T and =y, 

A positive atomic formula is an atomic formula concerning only positive 
terms. We denote positive atomic formulas by A. Ar represents a rigid positive 
atomic formula. 

A positive constraint is a constraint such that every eguation in it involves 
only positive terms. Cf represents a positive constraint. 

Definition 2 The set o/ definite clauses, with elements denoted D, and the set 
o/ goals, with elements denoted G, are sets of formulas, in X-normal form, de- 
fined by the following syntactic rules: 

D :=Ar\G^ Ar\ MxD 

G := A\Cp\Gi AG2 \Gi\/ G2\D ^ G\Cp ^ G \ 3 xG \ V*G 

A program is any finite set A of closed definite clauses. 

In order to simplify the technicalities, the construction Di A D2, usual in 
the literature for hoHH (e.g. [ 8 ]), is not considered here, but this restriction 
does not decrease the expressivity of the language, because a goal of the form 
Di A D2 => G can be simulated by (Di =y G) V {D2 => G), and a clause 
'ix{Di A D2) in a program can be replaced by two: MxDi, MxD2. On the other 
hand, notice that positive constraints can occur in goals, and therefore also in 
definite clauses. 

In the sequel, we assume an arbitrarily fixed effective constraint system C. 
Moreover, all constructions and results are valid for any constraint system, so 
we speak of a scheme hoHH[X) with instances hoHH{C). GLP and A-Prolog 
programs can be considered particular cases. As in GLP , the result of solving 
a goal G using a program A will be an answer constraint R such that G can 
be deduced from A and R by means of a proof system. But here we are aiming 
at an abstract logic programming language in the sense of [ 8 ]. So we need a 
proof system that guarantees the existence of a uniform proof for every provable 
sequent. This system will be presented in the next section, and it is a reduction 
of that presented before for the whole logic. 




A Higher-Order Logic Programming Language with Constraints 115 



4 Uniform proofs 

The idea of uniform proof in our system consists in breaking down a goal in 
its components until obtaining an atomic formula or a constraint, before using 
the rules for introduction of connectives on the left or resorting to constraint 
entailment. The proof system hoIC presented in Subsection 2.1 has not yet 
this property. We will transform /loTC-derivations for hoHH{C) into uniform 
derivations in two steps. First we will see that, for hoHH{C), the term that 
substitutes the predicate variable in the rule [Atomj) can always be positive, 
and that the auxiliary constraints of the rules (Vi) and (3/{) can also be positive. 
In a second step and taking into account the previous consideration, since the 
syntax of the formulas has been reduced, we show that some rules of the previous 
calculus can be omitted obtaining only uniform deductions, without reducing 
derivability, and preserving sequents containing only clauses, positive constraints 
and goals. In the next subsection the hrst step is tackled. Some technicalities are 
needed concerning positive terms. 

4.1 Positive terms and positive derivations 

The following mapping converts a term into a positive one. 

Definition 3 The function pos on terms t is defined as follows: 

{ T, iftisl. 

Xx : o.Xy : o.T, if t is =y 
t otherwise. 

ii) posftit'j) = posfti)posft 2 ) ■ III) posfiXx.f) = Xx.posff). 

Given a term t, U denotes A{pos{t)) and is called the positivization oft. 

We enunciate some known properties of the mapping pos and of the posi- 
tivization. If t e T, U e VT. If t e VT, U = t. For any ti, ^2 £ T, if ti 
A-converts to t 2 , then pos{ti) also A-converts to pos{t 2 ). 

Definition 4 The calculus hoXC^ is equal to hoIC, but replacing the rules 
[Atonij), (3/{) and (Vi) by the rules [Atom'j ), (3^) and (Vj), respectively, 
defined as follows. [Atom'j ) is defined like [Atomj), replacing the side condition 
T \~c X fa t, by T \~c X fa t, t (E. VT . (3^) is defined like (3/{), replacing the 
side condition T \~c ^yC , by T \~c ^yC , where C is positive. Analogous for 

(v^). 

Note that if [Xti . . .t„) is a goal, then ti, . . . ,t„ £ VT, hence the formula 
F in the premise of the rule [Atom'^) is also a goal, and that a hoXC^ -proof is 
also a hoXC-pioof. We are also interested in derivations that preserve sequents 
whose left-hand sides contain only clauses or positive constraints, and whose 
right-hand sides contain only goals. The Positivization Lemma below is the first 
step to attain this aim. Proving it we use the following notation and Lemma. 

If (T is a substitution [ti/Ni] . . . \tn/ XT\, where X\, . . . , are predicate vari- 
ables, we denote by cr+ the substitution)!)'' / Xi\ . . .\tf / Xn\. If F is a formula of 
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the form A{F'cr), replace every subformula of F' that is an equation, si ~ S 2 , 
by obtaining F” , then F* = A{F''cr'^). If 5 is a set of formulas, 

S* = {F*\F E 5}. The following properties can be proved: if T he df « t, 
then F* he df « T*" ; if _T he 3j/C, then F* he 3j/C*; if F he « Tr, then 
F* he A'; a;. 

Lemma 1 Let 0 be any set of formulas of the form 0 = {A{F'cr)\F' E 0'}, 
where 0' is a set of clauses or positive constraints, and let F = A{G'cr), where 
G' IS a goal. Let cr be any substitution of the form: [si/Yi] . . . [sr/Tr], where 
Yi,...,Yr are the predicate variables free in 0',G'. If 0\ — F has a hoIC- 
derivation, then 0* \ — F* has a hoIC^ -derivation. 

Proof By induction on the size of the proof of 0 | — F , analyzing cases depending 
on the last inference rule applied. The properties verihed by the entailment 
relation, mentioned before, are crucial in the proof. Some technicalities similar 
to that used in [8] for hoHH are also needed. ■ 



Lemma 2 (Positivization Proof Transformation) Let 0 be a finite set of 
clauses and positive constraints, and let G be a goal. 0 \ — G has a hoIC-derivation 
if and only if 0 \ — G has a hoIC^ -derivation. 

Proof The not obvious implication is a direct consequence of Lemma 1, taking 
(T as the identity, since we are considering only positive constraints and every 
clause or goal also contains only positive constraints. ■ 

If G is a goal and 0 is a set of formulas that is divided into a program A 
and a set of positive constraints F, we write the sequent 0| — G as A] F \ — G. 
Using the Positivization Proof Transformation Lemma, we will show the exis- 
tence of uniform proofs and the possibility of working with sequents of the form 

A;F^G. 

Lemma 3 (Uniform Proof Transformation) If G is a goal, A a program 
and F a set of positive constraint formulas, such that A] F \ — G has a proof of 
size I, then we can assure the following: 

1. If G = Pt\ . . .tm, P a predicate symbol, then there are n positive constraint 
Gi, . . .,G„ (n > 0^ and a formula of the form V*i . . .V*„ (G' => T() or 
V*i . . . Afi that IS a-eguivalent to a clause in A such that xi, . . . , x„ are 
new distinct variables not in Free{AU F U {Ar}), where, for 1 < i < n, Xi ^ 
Free{{Gi, . . . , Gi_i}) , and: 

(a) F he 3*iGi, F,Gi he 3*2G2,..., T, Gi, . . . , G„_i he 3*„G„. 

(bj T,Gi,...,G„ he T; 

(c) For the first case. A] F,G\, . . . ,Gn\ — G' has a proof of size less than 1. 

2. If G = Xti ...tm, X a predicate variable, there is t E VT , with Freeff) C 
Free[{ti, . . . , tmf), G' = A[fXti . . .tm)\t/X]) such that: 

(a) F he X^t. 

(b) A] F \ — G' has a proof of size less than 1. 
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3. IfG = Cp, then F he Cp. 

4-. If G = Gi AG 2 , then A; F \ — Gi and A; F \ — G 2 have proofs of size less than 
1. 

5. If G = G\\/ G 2 , then A; _T | — Gi has a proof of size less than I for i=l or 2. 

6. If G = D ^ Gi, then A, D] F \ — G\ has a proof of size less than 1. 

7. If G = Gp ^ G\, then A; F,Gp \ — Gi has a proof of size less than 1. 

8. For G = 3xG\, if y ^ Free{A U -T U {G}), then there is Gp such that: 

(a) F \~c 3yGp. 

(b) A; F, Gp I — Gi[y/x\ has a proof of size less than 1. 

9. If G = 'ixGi, then A; F \ — Gi[y/x] has a proof of size less than I, where 
y ^ Free[A U -T U {G}), 

Proof Since, by Lemma 2, the calculi hoIC and hoXC^ are equivalent for 
hoHFI[C), we can work always with positive constraints, therefore the proof of 
the lemma is similar to that of hrst-order [5], but including the case [Atom'j), 
because due to the syntax of clauses and goals, some rules like (3^) will not be 
applied. ■ 



4.2 The calculus halAC 

In this subsection we present an alternative proof system hoUC for hoHFI[C). 
Our motivation is the following: hoUC builds always Uniform proofs, and it is 
parameterized by a given Constraint system. \~hoUC replaces the left-introduction 
rules by a backchaining mechanism. 

With the help of Lemma 3 we can show that hoUC has the same derivable 
sequents of the form A] F \ — G as hoIC. 

Intuitively, /io7/C-derivations are closer to computations. Hence this proof 
system will be very helpful in the next section for designing a sound and complete 
goal solving procedure. 

Provability in hoUC is dehned as follows. A] F \~hoUC G if and only if the 
sequent A] F \ — G has a proof using the following rules. 

Axioms to deal with constraints and flexible atomic goals: 

{Gr), {Atom'j ), dehned as in the system hoIC^ . 

Backchaining rule for rigid atomic goals: 

A]F\ — 3xi .. .3x„{{A' Ar) AG) 

2-tkP 

where V*i . . .'ixn{G => A{) is a-equivalent to a formula of A, (or V*i . . .'ix„A{ 
is a-equivalent to a formula of A, and G = T), * 1 , ...,*„ do not appear free in 
the sequent of the conclusion. 

Rules introducing the connectives and guantifiers of the goals: 

(V_r), (A_r), (^r), (3+), (V_r), dehned as in the system hoIC^ . 

Now we can prove the intended equivalence between hoUC and hoIC. 
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Theorem 1 The proof systems hoIC and hoUC are equivalent for hoHH{C). 
That means, for any program A, for any set of positive constraints T, and for 
any goal G it holds: A; T \~hoic G if and only if A; T \~hoUC G. 

Proof The theorem is a consequence of the Uniform Proof Transformation 
Lemma 3, and the dehnition of calculi hoUC, hoIC. Both implications can be 
proved by induction on the size of the proof, analyzing cases on the structure of 

G. m 



5 A Goal Solving Procedure 

We now turn to the view of hoHH{C) as a logic programming language. Solving 
a goal G using a program A means to hud a C-satishable constraint R such that 
A] R \~hoUC G. Any constraint R with this property is called a correct answer 
constraint. 

We will present a goal solving procedure as a transition system. Goal solving 
will proceed by transforming an initial state through a sequence of intermediate 
states, ending in a hnal state. Each state will conserve the goals that remain to 
be solved and a partially calculated answer constraint. The hnal state will not 
have any goal to be solved. 

Definition 5 A state w.r.t. a finite set of variables V , written S , has the form 
n[SOQ] where: Q is a multiset of triples {A,G,G) (A local program, G lo- 
cal constraint and G local goal^. R is a quantifier prefix QiXi . . .QkXk where 
x\, . . . ,Xk are distinct variables not belonging to V , and every Qi, I < i < k, is 
the quantifier 'i or 3. S is a global constraint formula. 

We say that a state n[SOQ] is sati,sfiable when the associated constraint 
formula TTS, also called partially calculated answer constraint, is C-satishable. 

If iT', n are quantiher prehxes such that TT coincides with the hrst k elements 
of n , 0 < k < n, where n is the number of elements of iT, then Td — Td' represents 
the result of eliminating TT of iT. To represent a multiset Q, we will use the 
notation employed in the sequents for programs and constraints. That means we 
will use commas to express union and we will omit brackets. 

Definition 6 The rules for transformation of states, permitting to pass from 
a state w.r.t. a set of variables V, S, to another state w.r.t. V , S' , written as 
i5|| — S' , are the following: 

i) Conjunction. 

n[sag, {A, G, Gi A G 2 )] IH n[sag, {a, g, Gi), (zi, g, G 2 )]. 

ii) Disjunction. 

n[sag, {A, G, Gi V G 2 )] IH n[Sng, {a, G, G,-)], for i=l or 2 (don’t know 
choice). 

Ill) Implication with local clause. 

n[sng, {A, G,D^ G)] IH n[sng, {a u {d], g, g)]. 
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tv) Implication with local constraint, 

n[sug, {A, c, c ^ G)] IH n[sug, {a, c a c', g)]. 

v) Existential quantification, 

iJ[S'nCJ, (zi, C, 3*G)] II — iT3w[S'nCJ, (zi, G, G[w/*])], where w does not ap- 
pear m n nor m V. 
m) Universal quantification, 

iJ[S'nCJ, (zi, G, V*G)] II — iTVw[S'nCJ, (zi, G, G[w/*])], where w does not ap- 
pear m n nor m V. 
vn) Constraint, 

n[sag,{A,G,G')] ||- n[s A (g => G')ug]. if n(s a (g => g')) ^s c- 

satisfiable. 

mn) Clause of the program, 

n[Sug,{A,G,Ar)] IH iI[S'na,(zi,G, 3 * 1 ,,, 3*4(A; « A,) AG))], Pro- 
vided that ^ n UV, and V*i , , .'ixn{G => Zl)) is a-equivalent to 

some clause in A (or V*i ,,,V*„Zl) is a-equivalent to some clause in A, 
G =T) (don’t know choice). 

ix) Flexible atom, {A, G, (Xii . . ,G))] |H ^[S A (G =Z (3f « 

{A,G,G)]. Provided that G = A((Xti . . .tn)[t/X]), t E VT , Free(t) C 
Free{{ti . . .!„}), and II{S A (G =Z (3f « t))) is C-satisfiable. 

The following dehnition formalizes the setting needed for goal solving. 

Definition 7 The initial state for a proqram A and a qoal G is a state w.r.t. 
the set of free variables of A and G consistinq in So = [TD(zi, T, G)], 

Zl resolution of a goal G from a program A is a finite sequence of states w.r.t. 
the free variables of A and G, So, ■■■, S„, such that: 

• So IS the initial state for A and G. 

• i5i_i|| — Si, 1 Ai An, by means of any of the transformation rules. 

• The hnal state S„ has the form iT„[S'„n0], 

The constraint UnSn is called the answer constraint of this resolution. 

From the dehnition of the resolution procedure, it follows that every answer 
constraint is positive. The rule ix) corresponds to the rule [Atomy) of hoUC- 
calculus, and transforms a hexible atom in a (simpler) goal that, using the local 
constraint, can be proved to be equal to the atom. It is essentially the only new 
rule with respect to the goal solving procedure given in [5] for the hrst-order 
version of this language. Nevertheless as we will see in section 6, in the context 
of higher-order, these rules are more powerful in the sense that they solve more 
complex goals. This implies the incorporation of a system able to determine the 
satish ability of constraints in which higher-order equations may appear. 

This procedure is sound and complete in the following sense: 

Theorem 2 (Soundness) Let A be any proqram. If G is a qoal such that there 
IS a resolution So, ■■■ ,S„ of G from A with answer constraint R = IlnSn, then 
R IS C-satisfiable and A] R \~koUC G. 
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Theorem 3 (Completeness) Let A be a program, G a goal and Rq a positive 
C-satisfiable constraint such that A] Rq \~hoUC G. Then there is a resolution of 
G from A with answer constraint R such that Rq \~c R- 

The proofs of this theorems are equivalent of the corresponding ones included 
in [5] for hrst-order, but adding the case for the rule ix). 

In the next section we will see an example of the application of the state 
transformation rules i) to ix). 



6 Examples 



We begin referring to the example of the Introduction, that we have used to 
illustrate the expressivity of the language. 

Example 1 Let the program: 

A = {'ix'iy(x^ -\- K, 1 =y cil(x, y)), 

« 2 =y ci2{x, y)), 

'ix'iylx^ + 6 j/^ 2 =y el(x, y)), 

fig(cil), fig(ci2), fig(el), 

VCiVC 2 (/iff(Ci) Afig{G 2 ) AGi^G 2 => in{Xx.Xy.{Gi{x,y) A G 2 {x,y))))}. 

And let: 

G = 3T{in{T) A T{x, y)). 

We present a resolution of G from A: 



[TD(zi,T,3T(m(T)AT(*,j/)))]|K),) 

3T'[Tn{A, T, in{T')), {A, T, T'{x, J/))]|K „'0 

3T'3G[3G^[Ta{A, T, T' « Xu.Xv.{G[{u, v) A C' («, r;))), (zi, T,fig{G[)), 
{A, T,fig{G',)), {A, T, G[ 96 G',), {A, T, Tfx, j/))]|K„-) 



AV } ,V } A } A } A } 



AVin ],vin ) 



3r3C(3C'[r « Xu.Xv.{G[{u, v) A C'(«, T, G[ « cil), 



{A, T, « el), {A, T, G[ 96 G',), {A, T, Tfx, j/))]|K,p 



,vn ],vn ) 



3r3C(3C'[r « Xu.Xv.{G[{u, v) A C'(«, t;)) A « cil A C' « elA 
3r3C(3C^[r « Xu.Xv.{G[{u, v) A G! 



u , V } /\ A" 2 (u , v)) A G[ 



cil AG) Ki el A 



C'l 9 ^ {A, T, cil{x, y)), {A, T, el{x, t/))]|-h„'iO 



,V ],V ]A ),VIU ],V ],V]l] 



3r3C(3C^3*'3t/'3*"3t/"[r « Xu.Xv.{G[{u, v) A t;)) A « cilA 



C' « d A 96 Gi,a(A, T,x'^xAy'^ y), {A, T, x'^ + y'^ 
{A, T, x"^xA y" « y), {A, T, x"^ + &y"^ « 2)]|H 



1 ), 



I ],VU ]A ),VU ],VU ] ,VU ] 



3r3C(3C^3*'3t/'3*"3t/"[r « Xu.Xv.{G[{u, v) A C^(«, t;)) A « cilA 



C*2 ~ e/ A CJ 96 C*2 A * A j/' « j/ A + y'^ 



lA 



X Ay" Ki y A x"^ + 6y‘ 



,,//2 



2D] 



The answer is equivalent (in the constraint system TZ) to x^ + j/^ 



6 r 



2. That has two solutions: x 



V5 



Ay 



and x « \/2 A ; 



1 A 

0 . 
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The next simple example adds more explanation about the treatment of 

Example 2 Given the database: 

A = { annoyed (john), annoyed(jane), irntated(lomse) }, 
if we formulate the query: G = annoyed « irritated =y irritated(x ), the local con- 
straint annoyed « irritated is added to the database (rule iv)), then in accordance 
with the rules viii) and vii), the constraint solver should deduce, for instance, 
the satishability of annoyed « irritated =y (annoyed(john) « irritated(x)). We 
conclude that the goal G has the following possible answers: x « john, x « jane, 
X « louise. 

We hnish with an example in which we show how the benehts of HH based 
languages implementing modules ([7]) are improved with the use of constraints. 

Example 3 We follow the idea of identify a class of objects with a module of 
clauses. Then if a goal is used to send a message to an object, it will be solved 
in the presence of the corresponding module. In the example we dehne a module 
to represent the object class of employees^. 

MODULE stajf 
LOCAL Emp 

D\ = MVi si c[dataemp[Emp[l , s, c), I, s, c). 

D '2 = Hi si c{level{Emp{l , s, c),l). 

Ds = Hi si c[basesalary[Emp[l , s, c), s). 

= Hi si c{complement{E mp{l , s, c), c). 

D 5 = iEHisicipay{{level{E,l) A basesalary{E , s)A complement[E , c) A 
(0 < / < 3 => pay « ((s/12) + c) * 0.8)A 

(3 < / < 5 => pay fa ((s/12) + c) * 0.7)) => monthsalary[E , pay)) . 

If we want to know which is the level of an employee, whose pay in a month 
is $400, has a base salary of $4800 and a complement of $100, we send the 
message staff ==> 3E'{dataemp{E' ,1,4800, 100) A monthsalary{E' ,400)), that 
means i Emp[Di =y D 2 => H 3 => =y H 5 =y {3E'{dataemp{E' ,1,4800, 100) A 
monthsalary[E' , 400))) . The expected answer will be 0 < / < 3. 

7 Conclusions and Future Work 

The applications of CLP, and higher-order logic programming are well known. 
We have proposed a novel combination of CLP with higher-order HH with 
the purpose of summing up the advantages of higher-order programming, CLP 
and HH . For the amalgamated logic we present, a proof system and a goal 
solving procedure are included, showing the existence of uniform proofs as well as 
soundness and completeness of the resolution procedure w.r.t. the proof system. 

A related, but more limited approach, can be found in [ 6 ]. where it is shown 
how to manage hard constraints in a higher-order logic programming language 
like A-Prolog or Elf. But there, constraints are reduced to be equations over 

^ We use the reserved words that A-Prolog uses for modules. 
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terms, and higher-order unihcation is the constraint solving mechanism. Our 
results are parametric for more general constraint systems. 

In relation with functional logic programming languages with constraints, as 
Curry [3] , our language does not have the benehts of the evaluation of functions 
by rewriting rules. However, the advantages of hoHH(C ) w.r.t. Curry are manifest 
in expressiveness. 

An interesting issue that remains for future research concerns implementation 
techniques. For instance, the goal solving procedure is open to use incremental 
checkers that reuse the work previously done to stablish the satishability of a 
partially calculated answer constraint, to check the satishability of the next. The 
term t, that appears new in the rule tx), can be guess as a solution for A, solving 
the system II{S A C). In order to solve equations, it should be appropriate to 
dehne higher-order E-unihcation algorithms under a mixed prehx. We are also 
investigating decidable theories that can be useful as constraint systems. 
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Abstract. We investigate the fragment of intuitionistic logic consisting 
of hereditary Harrop formulas [MNPS91] as a specification language for 
security protocols. In this setting, embedded implications and universal 
quantification provide a natural built-in mechanism to model the dy- 
namics in the knowledge of the agents involved in a protocol. We take 
advantage of the system AProlog [NM88,NM99] in order to turn specifica- 
tions in hereditary Harrop formulas into executable prototypes, ready to 
be debugged. To exploit these features, we select as main case-study the 
well-known Needham-Schroeder protocol [NS78]. In this paper we report 
on the results of our experiments and we discuss potentially interesting 
directions of future research. 



1 Introduction 

Security protocols are often specified in a very informal way. As an ex- 
ample, let us consider the following rule of the well-known Needham- 
Schroeder protocol [NS78] (we will describe later in more detail): 

A^B-.{A,Na}K, 

The rule specifies a message sent from agent A to agent B. The message 
contains the identification of A, a fresh name (called nonce) Na, and 
it is encrypted with the public- key Kt, of B. This example shows that 
the language used to specify the protocol gives only a partial view of 
the knowledge that agents acquire while talking each other. Furthermore, 
side-conditions like ‘Nq is a fresh nonce’ are stated only at the meta-level. 
The use of informal specification may lead to ambiguous interpretations 
of the rules, and makes difficult the validation phase of the protocols. 

In this paper we present an experimental evaluation of intuitionic 
logic and more precisely of the fragment of hereditary Harrop formulas 
[MNPS91], hhffov short, as a potential specification language for security 
protocols involving a fixed number of principals. The features that make 
hereditary Harrop formulas appealing for the specification of security pro- 
tocols are described below. 

H. Kuchen and K. Ueda (Eds.): FLOPS 2001, LNCS 2024, pp. 123-137, 2001. 
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Dynamic Augmentation of Knowledge. Typically, at the initial stage of 
a protocol agents have very few information about the environment. The 
knowledge augments when messages are exchanged during the protocol. 
Via the use of embedded implications, the logic /i/i/provides a clean mech- 
anism to model dynamic augmentation of knowledge. For this purpose, 
we can in fact use implicational goals of the form D D G. When ex- 
cuted, such a goal enriches the current program with the clause D. The 
augmented program can be used then to refute the continuation goal G. 

Creation of New Names. As mentioned before, side conditions like ‘Aq is 
a fresh name’ are frequently used in the specification of security proto- 
cols. The logic /i/i/ provides a built-in mechanism to ensure the freshness 
of nonces created by the agents involved in the protocol via the use of 
universal quantification. For this purpose, in hhf we can use goals with 
universal quantification of the form Vx.G. When excuted, such a goal en- 
riches the signature of the current program with a new name c. The new 
environment can then be used to refute the continuation goal G\c/x\. 

Executable Specifications. Being an Abstract Logic Programming Lan- 
guage [MNPS91], /i/i/ programs enjoy a natural procedural reading that 
makes them executable specifications. The language AProlog provides in 
fact an interpreter [NM88] and a compiler [NM99] that can be used to 
run programs written in hhf. This is a crucial aspect in order to use a 
protocol specification as a prototype for debugging and testing. 

On the basis of the previous observations, our technical contributions 
are as follows. We present a general program scheme that can be used 
to model the main features of security protocols in the fragment hhf of 
intuitionistic logic. In this setting, we use /i/i/ program clauses to describe 
the actions of individual agents, the dynamics in their knowledge, and 
initial and final configurations for a successful execution of the protocol. 
Furthermore, we describe the potential moves of an intruder, and condi- 
tions under which the security of the protocol is broken by the intruder. 
As case-study, we present a detailed encoding of the well-know Needham- 
Schroeder public-key cryptography protocol. For this case-study, we have 
used the logic programming system AProlog as an automatic debugging 
tool. The results of this experiment are reported in the last section of the 
paper. Despite of the several proposed logics for reasononing about se- 
curity (see e.g. [BAN90,Mas99]), the problem of finding a general formal 
model for the specihcation and verification of security protocols is still 
an open problem. For this reason, we believe in the importance of inves- 
tigating existing techniques and tools like AProlog in order to find new 
insights into the problem. Also, we hope that our experiment will attract 
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the curiosity of other researchers looking for non-standard applications of 
logic programming tools. 

Plan of the paper. In Section 2, we introdnce the logic of hereditary 
Harrop formulas focusing on the operational reading of the corresponding 
logic programs. In Section 3, we present the case-stndy, i.e., the Needham- 
Schroeder Protocol. In Section 4, we define a general schema for specifying 
secnrity protocols in hhf. In Section 4.2, we present the hhf specification 
of the Needham-Schroeder protocol. In Section 5, we specify a generic hhf 
theory for intruders of public- key cryptography protocols. In Section 6, 
we briefly comment on the experiments we perform with the resulting hhf 
specification. In the experiments we specialize the intrnder theory to the 
case-study taken into consideration. Finally, we discnss related works and 
future directions of research in Section 7 and Section 8, respectively. 

2 An Operational View of Intnitionistic Logic 

The notion of Abstract Logic Programming (ALP) langnage [MNPS91] 
characterizes in a rigourons way fragments of intnitionistic logic that can 
be nsed as a platform to define logic programming languages. An ALP 
language is defined as a triple {T>,Q,\-) where T> is the set of program 
clauses, ^ is a set of goal formulas, and h is a provability relation snch 
that P h G is true if and only if there exists a uniform (i.e. goal driven) 
intnitionistic proof for the sequent P — > G. Hereditary harrop formnlas 
form one of the most interesting examples of ALP langnage. In the first- 
order case, program and goal formulas are defined as follows: 

G ::= T I A I Gi A Ga I Gi V G 2 I Vx.G | 3x.G | P D G, 
D::=A\GdA \ Vx.P. 

Let P be a set of P-formnla, and G a goal formula. The provability 
relation P h G is defined via the following meta-interpreter: 

T-R: P h T. 

A-R: P h Gi A Gi, if P h Gi AND P h Ga. 

V-R: P h Gi V Gi, if P h Gi OR P h Ga. 

D-R: P h P D G , if P, P h G. 

V-R: P h Vx.G, if P h G[c/x], where c does not occur free in G. 

Backchain: P h A, if there is a gronnd instance G D A of a clause in 
P snch that PPG. 

Clearly, Horn programs form a special class of hhf programs. Universal 
quantification and embedded implications add new interesting program- 
ming constructs to Horn programs. Specifically, implication in the goals 
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gives us the possibility of performing hypothetical reasoning. In fact, note 
that to prove D D G we first have to load D into the program, and then 
prove G. Also, note the difference between the goal D D {G\ A G 2 ) and 
the goal {D D Gi) A G 2 - In the first case D is loaded into the program to 
prove Gi A G 2 , whereas in the second one D is loaded into the program 
only to prove G\. In [Mil89], Miller has shown how implications can be 
used to give a modular structure to logic programs. Universal quantifi- 
cation allows the creation of fresh names during the execution of a goal. 
This idea has been used, e.g., to implement hiding mechanism for module 
systems [Mil89,Mil89b]. 

To sum up, proving that a formula G is a logical consequence of a 
program P in intuitionistic logic, amounts to search for a goal-driven 
proof of P h G. This can be done automatically in the incomplete theorem 
prover AProlog [NM88]. As Prolog, AProlog combines in fact a left-to-right 
selection rule with a depth- first search of successful derivations. 

3 The Needham-Schroeder Protocol 

In this paper we will mainly focus our attention on public-key cryptography 
protocols. In this setting, any agent (principal) involved in the protocol 
has a pair of keys: a public key, and a secret key. Typically, the secret key 
of agent A is used to decipher messages (encrypted with A’s public key) 
that other agents send to A. To give a concrete example, in the rest of the 
section we will briefly describe the security protocol based on public-key 
cryptography proposed by Needham and Schroeder in [NS78]. The pro- 
tocol allows two principals, say Alice and Bob, to exchange two secret 
numbers. The secret numbers will be used later for signing messages. The 
core of the protocol is defined as follows. Assume that Alice knows the 
public key of Bob (e.g. it asks for it to a certification authority). As a 
first step, Alice creates a nonce Na and sends it to Bob, together with its 
identity. A nonce is a randomly generated value used to defeat ‘playback’ 
attacks. The message is encrypted with Bob’s public key, so that only Bob 
will be able to decipher the message. When Bob receives the message, he 
creates a new nonce N^. Then, he sends the message (Na,Nf) encrypted 
with the public key of Alice. Alice decrypts the message, and sends back 
the nonce W encrypted with the public key of Bob. At this point, Al- 
ice and Bob know the two secret numbers Na and N^. In synthesis, the 
protocol has the following rules 



1. A - 


B 


{A, Na]Kt, 


2. .B - 


A 


{Na,N^]K 


3. A - 


B 
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The previous specification does not take into account the presence of po- 
tential intruders. Intruders might intercept messages, and use them to 
cheat the two principals. In order to validate security protocols it is fun- 
damental to model the knowledge of each participant during the execution 
of the protocol, and to model the possible actions that an intruder can 
take in order to break the security of the communication. In the following 
sections we will show how to exploit the features of the fragment hhf of 
intuitionistic logic in order to achieve the previous goals. 

4 Specifying Security Protocols in hhf 

Before focusing on our case-study, we will describe some general ideas 
that can be used to specify a security protocol using intuitionistic logic. 
For simplicity, we will focus on protocols involving two agents, we call A 
and B in order to distinguish the general case from the case-study. As 
illustrated in Section 3, security protocols are typically specified via a 
sequence of rules having the following form 

Agenti — > Agent2 '■ Msg. 

Here Agenti and Agent2 are the agent names, Exp is an expression 
represing encrypted messages, that in turn may include the agent names, 
nonces, time-stamps, and other encrypted messages. The rules represent 
the sequence of steps the two agents must perform to successfully termi- 
nate the protocol. In order to transform these rules into non ambiguous 
specifications it is necessary to formally represent the change of the knowl- 
edge of A and B when a message is successfully delivered to one of them. 
To achieve this goal using hhf, we first need to symbolically represent 
the current state and knowledge of the agents, and the global information 
available on the network. Specifically, in order to model the state of the 
network during the execution of the protocol we use the atomic formula 

{state StatcA States Statejy), 

where StatcA, States, and States represent the current state of A, B 
and of the communication channel N between A and B, respectively. 
We assume that each principal has a finite set of possible states (that 
correspond to the steps of the protocol) denoted as non-logical constants 
(e.g. aliceQ,alicei, . . . if alice is Alice’s identifier). N will represent the 
messages sent by the agents. In this paper we will consider communication 
via a one-place buffer, no_msg being the empty buffer (other possible 
communication models like FIFO channels can be easily modeled using 
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appropriate data structures). Encrypted messages we will be represented 
via terms having the following form 

{enc Key Message), 

where Message can be either a non- logical symbol, a pair of messages 
(Ml, M2), and so on. We will discuss later how to represent nonces. Global 
information can be represented via a collection of unit clauses (facts) . For 
instance, a fact like 

(keypair Agent PrivateKey PuhlicKey) 

can be used to represent the initial knowledge of an agent in a public-key 
cryptography protocol. Furthermore, we can use the fact 

(announce PublicKey), 

if we assume that a trusted entity makes the public keys of all the prin- 
cipals available on the network (we assume that agents contacts other 
agents selecting their public keys). Alternatively, in a protocol based on 
secret-key cryptography the fact 

(secretkey Agent SecretKey) 

will represent the initial knowledge of an agent. We are ready now to 
describe the mechanisms needed to model protocol rules. 

4.1 The Dynamics of the Network 

Protocol rules specify how the knowledge of agents must be updated. 
More precisely, suppose that during the fc-step of the protocol an agent 
B hrst receives the message Mi from B (i.e., A ^ B : Mi), and then 
it replies with message M2 (i.e, B ^ A: M2). Also, suppose that the 
current state of B will change from States to State'^ (e.g. from alicck-i 
to alicck). Then, the current knowledge of B must be updated with all 
the information that B is able to extract from Mi. Furthermore, we have 
to ensure the freshness of all nonces created by B and included in M2- 
We model all of these aspects in hhf as follows. We first represent the 
current knowledge of an agent A using a collection (i.e. conjunctions) of 
facts having the form 

(knows Agent M), 

where M can be any kind of information (messages, keys, time-stamps, 
nonces, and so on). Then, we consider h/i/ clauses having the following: 

(VA^i 'iNm- (G A (U D S'))) D s, 



where 
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P,U[c/a;] h S' 

P h G P h U[c/Al] D S'[c/N] 

P h G[c/Ai] A (UdS')[c/A^ 1 
P h ViV.(G A (U 3 S')) 

P h S 

where WN. (G A (U 3 S')) 3 S G P, and c is a new name. 



Fig. 1. Proof scheme for the protocol theory. 



— S = {state StatcA States M±) is the current network state, 

— S' = {state StateA State'^ M 2 ) is the new state of the network, 

— U = {knows B mi) A ... A {knows B mq) is the update of 
B’s knowledge {m±, . . . ,mq being the pieces of information that B 
manages to extract from Mi), 

— G (the guard) is a goal formulas used to extract information from Mi , 
and to build the message M 2 , 

— A^i, . . . ,Nm are the new nonces created by B (as explained before, 
modeled via universally quantified variables), with the proviso that 
they do not occur free in G. 

The effect of applying this kind of rules in a backchaining step is described 
by the proof scheme in Fig. 1. Note that, the left branch of the scheme 
in Fig. 1 is used to check the ‘guard’ G against the current global infor- 
mation, whereas the right branch is used to update the agent knowledge 
and to create the new names. 

Setting up the Initial Scenario. As an example, the hhf rule we can use 
to set up the initial scenario of a security protocol based on public-key 
cryptography with two principals is as follows 

yPKa,PK,,SKa,SKh. 

{{{keypair A SKa PKa) A {keypair B SKf, PKb) A {announce PKa) 

A {announce PK^)) D {state InitA Inits no^msg)) 

D {initialize A InitA B Inits). 

Note that, in the previous formula there is no G-component (its use will be 
illustrated in Section 4.2); the body of the clause consists of a universally 
quantified G-formula containing an implicational subgoal. The universal 
quantification in the body ensures that all the keys will be fresh and 
distinct from each other. 
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Termination of the protocol. Following the ideas presented in the previous 
sections, the execution of a protocol can be viewed as a derivation that 
leads from (initialize . . .) to a state in which the agents have achieved 
their goals (e.g. Alice and Bob receive the nonces). The successful termi- 
nation of the protocol can be expressed then via clauses like 

G D (state Final A Finals Network), 

where G is used to check that the requirements of A and B are satisfied in 
the final global state. In other words, (initialize . . .) will have a refutation 
in the /i/i/ theory obtained merging rules and agents goals if and only if 
there exists a successful execution of the protocol. Let us apply these 
ideas to our case-study. 

4.2 The hhf Theory for Needham-Schroeder 

Let alice and bob be the symbolic names for the two principals. 

Initial States. Invoking the goal (initialize alice aliceo bob bobo) (see 
previous Section) will create the initial scenario for our protocol. 

Protocol Rules. The rules of Alice and Bob’s are defined using the general 
schema of Section 4. As an example, when in state aliccQ Alice must create 
a new nonce Na, and send it to Bob. As a side-effect, her knowledge should 
be augmented with the information ‘Alice knows A^’. Formally, we encode 
the first rule of the protocol as follows: 

V A,. 

((keypair alice SKa PKa) A (announce K^) A 
((knows aliceo Na) D (state alice\ Bob (enc Kf, (Na, PKa))))) 

D (state aliceo Bob nojnsg). 

Here the G-formula (keypair alice SKa PKa) A (announce K\f) is used 
as a guard (i.e. G-component) to retrieve Bob’s public key and to build 
the initial message. Similarly, the reply from Bob is defined as follows: 

VAb. 

((keypair bob SKi, PK^f) A 

(((knows bobo Na) A (knows bobo Ka) A (knows bob\ N^)) 

D (state Alice bob\ (enc Ka (Aq, Af,))))) 

D (state Alice bobo (enc PK^ (Na, Ka))). 

Finally, the second rule for Alice is defined as follows: 

((keypair alice SKa PKa) A (knows aliceo Na) A (knows aliceo Kh)A 
((knows alicei Nf,) D (state alicc 2 Bob (enc K\, Nf,)))) 

D (state alicei Bob (enc PKa (Na,Nfj))). 
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Termination. The protocol terminates successfully if Bob receives the 
nonce he created. We can specify this requirement as the following 
clause. 

{{keypair bob SK^ PK^) A {knows bob\ Nh)) 

D {state Alice bob\ {enc PK\, Nf,)). 

In the ideal setting where only Alice and Bob are connected on the net- 
work the goal {initialize alice aliccQ bob bobo) will have a refutation in 
the hhf theory consisting of the previous clauses, called V, if and only if 
the protocol is safe (e.g. it has no deadlocks). We discuss next the problem 
due to the presence of malicious agents. 

5 The Intruder Theory 

In order to test a protocol it is necessary to specify the actions of potential 
intruders. Following [CDKS00,Mas99], an intruder can be viewed as an 
agent with public and privat keys who has the capability of decomposing 
and storing all messages he receives. Furthermore, intruders can create 
new nonces and compose new messages using the information they stored 
(e.g. composing a new messages using old nonces). To formalize this idea, 
we consider one possible intruder, called Trudy, and we incorporate her 
state into the global state as follows 

{state A B Trudy Network). 

Trudy must be considered as just another user, she will intervene only if 
some agent contacts her. The capabilities of Trudy in a generic public-key 
cryptographic protocol can be specified via the following rule (where we 
use trudy as identifier). 

VW.VW. 

{{keypair trudy SKt PKt) A {announce Kf,) A 
{{{knows trudy Nt) A {knows trudy Ng) A {knows trudy M\) 

A {knows trudy M 2 )) 

D {{composezmsg M) A {state A B trudyi+i {enc Kt, M))))) 

D {.state A B trudyi {enc PKt {Mi, M 2 ))). 

Note that, the subgoal in the body of the previous clause has the follow- 
ing form G A (U D (G' A S')), where G' is used to check conditions 
after the update of Trudy’s knowledge. The predicate composc-msg non- 
deterministically generates all possible messages starting from the current 
knowledge of the intruder. Formally, 

{composc-msg M) A {composc-msg N) D {composc-msg {M,N)). 
{knows trudyi M) D {compose-msg M). 
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Trudy also has the capability of sending messages to all agents she knows: 

yNt.yNs. 

{{keypair trudy SKt PKt) A {knows trudyany_step PK) A 
{{{knows trudy Nt) A {knows trudy Ng) A 
{knows trudy Mi) A {knows trudy M 2 )) 

D {{composejmsg M) A {state A B trudyi+i {enc PK M))))) 

D {state A B trudyi {enc PKt {Mi, M 2 ))). 

Similar rules can be given for atomic messages. We will call X the theory 
consisting of the previously described clauses. In order to test a protocol it 
also necessary to identify potential violations. Clearly, violations depend 
on the protocol taken into consideration. We will discuss how to specify 
them in hhf for our example. 

5.1 Specifying the Attacks for Needham-Schroeder 

As mentioned in Section 3, the goal of Alice and Bob is to learn the nonces 
Na and Nf,. What is the goal of Trudy the intruder? She would like to learn 
the nonces Na and Nh without affecting the termination of the protocol, 
i.e., Alice and Bob should not realize that the intruder has intercepted 
their messages. Since the attack is valid only if the protocol succeeds for 
Bob, we proceed as follows. Let VA be the /i/i/ theory obtained from the 
theory V of Section 4.2 extending the predicate state with the parameter 
Trudy (never modified). Then, we turn the termination clause of V into 
the following new one: 

{keypair boh SKf, PK^) A {knows bobo Na) A {knows bobi Nf,) A 
{knows aliccQ Na) A {knows alicei N^) A 
{knows trudy Na) A {knows trudy N^) 

D {.state Alice bobi Trudy {enc PKf, Af,)). 

Now, let T = VA U X (X is the intruder theory of Section 5). All deriva- 
tions of the goal {initialize alice aliccQ bob bobo trudy trudyo) (the natu- 
ral extension of the initialization theory to the 3 agents case) correspond 
to all interleaving executions of the protocol and of the attacks of the 
intruder. Formally, if X h {initialize alice aliceo bob bobo trudy trudyo) 
holds, then the intruder has a strategy to learn the nonces exchanged 
by Alice and Bob without influencing the termination of the Needham- 
Schroeder protocol. Since a priori we do not know how many actions are 
needed for the intruder to find the attack, we can fix a bound on the 
depth of the search (i.e. number of states) of the intruder, and iterate the 
execution of the goal initialize for increasing bounds. Clearly, this way we 
can only debug the protocol (if an attack exists we will find it). 
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{{knows-key trudyo K) A {knows trudyo M) A 
{state Alice Bob {enc PK {M,K)) Trudy)) 

3 {chooseM sgKey Alice Bob Trudy PK). 

{{knows trudyo M\) A {knows trudyo M2) A 

{state Alice Bob Trudy {enc PK (Mi, M2)))) 

D {chooseMsgMsg Alice Bob Trudy PK). 



Fig. 2. Generation of Trudy’s messages. 



6 Practical Experiments using AProlog 



The hhf specification T we introduce in the previous sections can be di- 
rectly turned into a AProlog program. Since the interpreter of AProlog 
uses an incomplete strategy to find refutations, in our experiments we 
avoid possible infinite derivations by considering intruders with four pos- 
sible states {trudyo through trudyo) and messages encoded by terms of 
depth one. Furthermore, to reduce the non-determinism of the intruder, 
we specialize the intruder theory in order to take into account the struc- 
ture of messages exchanged by Alice and Bob in the protocol taken into 
consideration. For this purpose, we introduce a new predicate knows-key 
to store information about public keys. The specialization of the intruder 
theory is based on the following assumptions. Alice’s first message con- 
tains a public-key. Trudy will probably try to susbtitute Alice’s public-key 
with a key she has stored in a previous step. To create Trudy’s messages 
we use two predicates chooseMsgKey and chooseMsgMsg dehned in Fig. 
2. The first predicate generates all possible pairs message- key whose com- 
ponents are known by the intruder. The second one generates all possible 
pairs message-message. The two predicates described above are incor- 
porated into Trudy’s theory as shown in Fig. 3. In order to debug the 
Needham-Schroeder protocol, we execute the goal 



{initialize alice aliceo bob bobo trudy trudyo) A fail, 



where fail is used to explore all alternatives in backtracking. All possible 
refutations of the hrst subgoal will result in strategies for Trudy to reach 
her goal. By including an auxiliary ‘history’ parameter, we automatically 
found two strategies for Trudy. The first strategy consists of the following 
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yNt. 

{{keypair trudy SK PK) A {announce PKb) 

{{{knowsJtey trudyo PK) A {knowsJtey trudyo PKb) A 
{knowsJkey trudyo M\) A {knows trudyo M2) A {knows trudyo Nt)) 
D {chooseM sgKey Alice Bob trudyi PKb))) 

3 {state Alice Bob trudyo {enc PK {Ml, M2))). 

{{keypair trudy SK PK) A {knowsJtey trudyo PKa) A 
{{{knows trudyo M\) A {knows trudyo M2)) 

D {chooseM sgM sg Alice Bob trudy2 PKa))) 

D {state Alice Bob trudyi {enc PK {Mi, M2)))). 

{{keypair trudy SK PK) A {knowsJtey trudyo PKb) A 
{{knows trudyo M) D {state Alice Bob trudyo {enc PKb M)))) 

D {state Alice Bob trudy2 {enc PK M)). 

Fig. 3. Specialized Trudy’s theory. 



steps. 

1. Alice Trudy : {TVa, Ka]Kt 

2. Trudy Bob : {Nt, Kt}Kt 

3. Bob Trudy : {Nt, Nb}Kt 

4. Trudy Alice : {Na, 

5. Alice — > Trudy : {Nb}Kt 

6. Trudyi Bob : 

This strategy corresponds to the one found by Lowe in [Low96]. Here 
Alice first contacts Trudy instead of Bob. At this point, Trudy opens a 
new session with Bob. Alice and Bob exchange the secret numbers and 
conclude the protocol successfully. However, Trudy learns all the secret 
information. In the second strategy we found, Trudy does not open a 
connection as a ‘normal’ agent (i.e. creating a new nonce etc). It simply 
passes the nonce he got from Alice to Bob. More precisely, the second 
strategy consists of the following steps. 

1. Alice Trudy : {Na, Ka]Kt 

2. Trudy — > Bob : {Na, KAkk 

3. Bob Trudy :{Na,Nb}Ki 

4. Trudy Alice : {Na, Nbjxa 

5. Alice — > Trudy : {Ni,}^! 

6. Trudyi Bob : {Ni,}k,, 

The AProlog code of the protocol specification is available at the following 
URL: http:/ /www.disi. unige.it/person/DelzannoG/. 
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7 Related Works 

In the last years many works have been devoted to the analysis of se- 
curity protocols. Besides case-studies like [Low96], many efforts have 
been spent in order to hnd appropriate logics [BAN90,Mas99], languages 
[CDL+99,DY83], and tools [CJM98,CJM00,Mea96], to face the problem 
of protocol validation in a general way. In the seminal work [BAN90], 
Burrows, Abadi and Needham invented the logic BAN to reason about 
security. The logic provides constructs to specify beliefs of agents and 
to describe their modification as an effect of the interaction with the 
environment. Being a specialized logic, BAN is a very rich specification 
language, that however does not have an immediate operational reading. 
Recently, Cervesato et al. [CDL+99,CDKS00,CDL+00] have studied and 
compared several models (including Dolev-Yao [DY83]) with specifica- 
tion languages closer to the logic programming perspective, i.e., enjoying 
a simple procedural view. In [CDL"’"99] (an important inspiration for our 
experiments) Cervesato et al. showed that multiset rewriting systems en- 
riched with a mechanism for handling the generation of new names (uni- 
versal quantihcation) is a suitable formalism to model several security 
protocols in a uniform way. The logic underlying the language is Girard’s 
linear logic [Gir87]. Differently from our encoding, in [CDL"''99] the in- 
formation of an individual agent is encoded inside atomic predicates (like 
bob{keypr, keypb, keyaUce-, ■ ■ •))> updated via rewriting steps. With our 
work, we have tried to show that ideas coming from intuitionistic logic 
could be useful as well in this setting. In particular, we have used em- 
bedded implications in order to model in an elegant way the update of 
knowledge. This way, implications in goal formulas can be viewed as a 
built-in operator whose semantics is described by the underlying logical 
system. 

8 Conclusions and Future Work 

The more important restriction we had to face while experimenting the 
specification of the Needham-Schroeder protocol in AProlog was on the 
number of players involved in the game. (In many practical cases it is in 
fact possible to put bounds on the depth of messages [BAN90,CDL+99]). 
While it is relatively simple to handle a finite number of agents, it is not 
clear yet if the same ideas could be applied to the general case of a multi- 
agent communication protocol. An interesting direction could be the use 
of a combination of aspects of linear and intuitionistic logic, achieved 
in languages like Forum [Mil96]. In this setting it could be possible to 
specify locally the actions of single agents (as in [CDL+99]), whereas the 
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knowledge common to all agents could still be modeled using the ‘intu- 
itionistic component’ of Forum. Without fixing the number of principals 
in the initial stage of the protocol, it could still be very difficult to use 
the resulting specification for debugging. To attack this problem, in our 
opinion there are at least two interesting directions to investigate. 

The first one is the use of a meta-logic to reason about specifications 
in languages like /i/i/and Forum. Embedding the logic specification within 
a meta-logic like the one described in [MM97] could give in fact a further 
tool in order to study intensional properties (i.e., that do not require an 
explicit state exploration [CJM98]) of security protocols. 

The other direction concerns alternative execution models for (linear 
logic and/or intuitionistic-based) specifications that do not require to fix 
an initial state (i.e. that work independently by the number of agents in 
the system) . Bottom- up evaluation of logic programs and linear logic pro- 
grams (see e.g. [BDM00,BDM01,Hui92]) could be a potentially interesting 
tool for achieving this goal. 

Acknoledgements. The author would like to thank the anonymous referees 
for their usefule suggestions that helped us to improve the presentation. 



References 



[BDMOO] 

[BDMOl] 

[BAN90] 

[CDL+99] 

[CDKSOO] 

[CDL+00] 

[CJM98] 

[CJMOO] 

[DY83] 

[Gir87] 



M. Bozzano, G. Delzanno, and M. Martelli. A Bottom-up semantics for 
Linear Logic Programs. In Proc. PPDP’OO, page 92-102, 2000. 

M. Bozzano, G. Delzanno, and M. Martelli. An Effective Bottom-up Se- 
mantics for First-Order Linear Logic Programs. To appear in Proc. FLOPS 
2001, March 2001. 

M. Burrows, M. Abadi, R. M. Needham. A Logic of Authentication. TOCS 
8(1): 18-36, 1990. 

I. Cervesato, N. Durgin, P. Lincoln, J. Mitchell, and A. Scedrov. A Meta- 
Notation for Protocol Analysis. In Proc. Computer Security Foundations 
Workshop CSFW’99, pages 28-30, 1999. 

I. Cervesato, N. Durgin, M. Kanovich, and A. Scedrov. Interpreting 
Strands in Linear Logic In Proc. of Formal Methods and Computer Security 
FMCS’OO, 2000. 

I. Cervesato, N. Durgin, P. Lincoln, J. Mitchell, and A. Scedrov. Relating 
Strands and Multiset Rewriting for Security Protocol Analysis. In Proc. of 
Computer Security Foundations Workshop CSFW’OO, pages 35-51, 2000. 

E. Clarke, S. Jha, W. Marrero. Using State Space Exploration and a Natural 
Deduction Style Message Derivation Engine to Verify Security Protocols. In 
Proc. of PRO-COMET’98, 1998. 

E. Clarke, S. Jha, W. Marrero. Partial Order Reductions for Security Pro- 
tocol Verification. In Proc. of TACAS 2000, pages 503-518, LNCS 1785, 
2000 . 

D. Dolev and A. Yao. On the Security pf Public-key Protocols. IEEE 
Transactions on Information Theory, 2(29), 1983. 

J. Y. Girard. Linear logic. Theoretical Computer Science, 50:1-102, 1987. 




Specifying and Debugging Security Protocols 137 



[HM94] J. Hodas and D. Miller. Logic Programming in a Fragment of Intuitionistic 
Linear Logic. Information and Computation, 110(2):327-365, 1994. 

[Hui92] A. Hui Bon Hoa. A Bottom-Up Interpreter for a Higher-Order Logic Pro- 
gramming Language. In Proc. PLILP 1992, pages 326-340, LNCS 631, 1992. 

[Low96] G. Lowe. Breaking and Fixing the Needham-Schroeder Public-key Protocol 
usinmg CSP and FDR. In Proc. TACAS’96, page 147-166, LNCS 1055, 1996. 

[Mas99] F. Massacci. Automated Reasoning and the Verification of Security Proto- 
cols In Proc. of TABLEAUX ’99, pages 32-33, LNAI 1617, 1999. 

[Mea96] C. Meadows. The NRL Protocol Analyzer: An Overview. JLP 26(2): 113- 
131, 1996. 

[MM97] R. McDowell, D. Miller. A Logic for Reasoning with Higher-Order Abstract 
Syntax. In Proc. LICS ’97, pages 434-445, 1997. 

[Mil89] D. Miller. Lexical Scoping as Universal Quantification. In Proc. ICLP ’89, 
pages 268-283, 1989. 

!Mil89bl D. Miller. A Logical Analysis of Modules in Logic Programming. JLP 
6(1&2): 79-108, 1989. 

[Mil96] D. Miller. Forum: A Multiple-Conclusion Specification Logic. Theoretical 
Computer Science, 165(l):201-232, 1996. 

[MNPS91] D. Miller, G. Nadathur, F. Pfenning, and A. Scedrov. Uniform Proofs as 
a Foundation for Logic Programming. Annals of Pure and Applied Logic, 
51:125-157, 1991. 

[NM88] G. Nadathur and D. Miller. An Overview of A-Prolog. In Proc. of ILPS/SLP 
’88, pages 810-827, 1988. 

[NM99] G. Nadathur, D. J. Mitchell. System Description: Teyjus - A Compiler 
and Abstract Machine Based Implementation of lambda-Prolog. In Proc 
CADE’99, LNCS 1632, pages 287-291, 1999. 

[NS78] R. M. Needham and M. D. Schroeder. Using Encryption for Authentication 
in Large Networks of Computers. CACM 21(12): 993-999, 1978. 




An Effective Bottom-Up Semantics for 
First-Order Linear Logic Programs 



Marco Bozzano, Giorgio Delzanno, and Maurizio Martelli 



Dipartimento di Informatica e Scienze dell’Informazione 
Universita di Genova 
Via Dodecanese 35, 16146 Genova - Italy 
{bozzano ,giorgio ,martelli}@disi .unige . it 



Abstract. We study the connection between algorithmic techniques for 
symbolic model checking [ACJT96,FS98,AJ99], and declarative and op- 
erational aspects of linear logic programming [And92,AP90]. Specifically, 
we show that the construction used to decide verification problems for 
Timed Petri Nets [AJ99] can be used to define a new fixpoint semantics 
for the fragment of linear logic called LO [AP90]. The fixpoint semantics 
is based on an effective Tp operator. As an alternative to traditional top- 
down approaches [And92,AP90,APC93], the effective fixpoint operator 
can be used to define a bottom-up evaluation procedure for first-order 
linear logic programs. 



1 Introduction 

Since its introduction in [Gir87], linear logic has been understood as a frame- 
work to reason about concurrent computations. Several researcher have in fact 
observed the existence of natural connections between linear logic and the theory 
of Petri Nets, see e.g., [Cer95,Kan94,MM91]. In this work we will investigate this 
connection focusing on the relations between algorithmic techniques used for the 
analysis of Petri Nets and provability in fragments of linear logic. The fragment 
we consider in this paper is called LO [AP90]. LO was originally introduced as a 
theoretical foundation for extensions of logic programming languages [And92] . As 
we will show next, LO programs enjoy a simple operational reading that makes 
clear the connection between provability in linear logic and verification methods 
in Petri Nets. Let us illustrate these ideas with the help of some examples. 

Petri Nets in Propositional Linear Logic. Following [MM91], a Petri Net 
can be represented as a multiset-rewriting system over a finite alphabet p,q,r, . . . 
of place names. Among several possible ways, multiset rewrite rules can be ex- 
pressed in linear logic using the connectives ^ (multiplicative disjunction), and 
o- (reversed linear implication). Multiplicative disjunction plays the role of mul- 
tiset constructor, whereas linear implication can be used to define rewriting rules. 
Both connectives are allowed in the fragment LO. For instance, as shown in 
[Cer95] the LO clause 

p'^q o- p^p^q^t 
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can be viewed as a Petri Net transition that removes a token from places p and 
q and puts two tokens in place p, one in q, and one in t. Being a first-order 
language and thanks to the presence of other connectives, LO supports more 
sophisticated specifications than Petri Nets. For instance, Andreoli and Pareschi 
used LO clauses with occurrences of ^ and & (additive conjunction) in their 
body to express what they called external and internal concurrency [AP90]. 

In our previous work [BDMOO], we have defined an effective procedure to 
evaluate bottom-up LO propositional programs. Our construction is based on 
the baekward reaehability algorithm of [ACJT96] used to decide the so called 
eontrol state reaehability problem of Petri Nets (i.e. the problem of deciding if 
a given set of configurations are reachable from an initial one). The algorithm 
of [ACJT96] works as follows. Starting from a set of target states, the algorithm 
computes symbolically the transitive closure of the predeeessor relation of the 
Petri Net taken into consideration (predecessor relation=transition relation read 
backwards). The algorithm is used to check safety properties: if the algorithm is 
executed starting from the set of unsafe states, the corresponding safety property 
holds if and only if the initial marking is not in the resulting fixpoint. 

In order to illustrate the connection between backward reachability for Petri 
Nets and provability in LO, we first observe that LO clauses like 

Ai o- T 

plays the same role that faets (unit clauses) do in logic programming. In fact, 
when applied in a resolution step, they generate instances of the LO axiom 
associated to the connective T (one of the logic constants of linear logic). Now, 
suppose we represent a Petri Net via an LO program P and the set of target 
states using a collection of LO facts T. Then, the set of logieal eonsequenees 
of the LO program PUT will represent the set markings that are backward 
reachable from the target states. The algorithm we presented in [BDMOO] is 
based on this idea, and it extends the backward reachability algorithm for Petri 
Nets of [ACJT96] to the more general case of propositional LO programs. This 
connection can be extended to more sophisticated classes of Petri Nets, as we 
discuss next. 

Timed Petri Nets in First-Order Linear Logic. In Timed Petri Nets 
[AJ99], each token carries along its age. Furthermore, transitions are guarded 
by conditions over the age of tokens. To model the age of each token we can 
lift the specification in linear logic from the propositional to the first-order case. 
Basically, we can use an atomic formula p{n) to model a token in place p with 
age n. For instance, the first-order linear logic rule (where for convenience, we 
use ... □ c to denote a eonstrained formula in the style of Constraint Logic 
Programming [JM94]) 

p{X) '^p{Y) o- r(Z) DX<1, Y>2, Z>1 

can be read as a diserete transition of the Timed Petri Nets of [AJ99] that 
removes a token from place p if its age is less equal than 1, a token from place p 
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if and only if its age is greater or equal than 2, and adds a token with age greater 
or equal than 1 to place r. The previous clause can be seen as a compact way 
for expressing an infinite set of clauses (one for every evaluation of the variables 
which satisfies the constraints). 

Recent results [ACJT96,AJ99] show that the control state reachahility prob- 
lem, under suitable hypothesis, is still decidable for Timed Petri Nets. The prob- 
lem can be solved using the backward reachability algorithm of [ACJT96] in com- 
bination with a symbolic representation of sets of global states of Timed Petri 
Net via the so called existential regions [AJ99]. Now, can we exploit the results 
of [AJ99] for first-order (or even better, constrained) TO programs? 



Our Contribution. In this paper we will show that it is possible to extend 
the parallel between the results on Petri Nets and provability in propositional 
TO, to new results relating Timed Petri Nets and provability in first-order LO. 
Specifically, we define a bottom-up fixpoint semantics for first-order LO pro- 
grams (actually, we will consider the more general case of LO programs with 
constraints) using a generalization of the backward reachability algorithm for 
Timed Petri Nets of [AJ99]. Our procedure is a generalization in the following 
sense: we abstract away from the specific domain of Timed Petri Nets (e.g. where 
constraints are the clock constraint of [AJ99]); we handle the entire class of first- 
order LO programs (i.e. with nested occurrences of ^ and & in the body of 
clauses) . The resulting fixpoint semantics is based on an effective fixpoint opera- 
tor and on a symbolic and finite representation of potentially infinite collections 
of first-order provable LO (atomic) goals. The termination of the fixpoint com- 
putation cannot be guaranteed in general, first-order LO programs are in fact 
Turing complete. As a consequence of the results in [AJ99,AN00], for a class of 
first-order LO programs that includes the discrete component of the Timed Petri 
Nets of [AJ99] the fixpoint semantics can be computed in finitely many steps. 

Besides the relationships with Petri Nets, the new fixpoint semantics for first- 
order LO programs represents an interesting alternative to the traditional top- 
down semantics for linear logic programs studied in the literature [And92,AP90]. 
Our construction gives in fact an effective (though not complete) algorithm for 
the bottom-up evaluation of LO programs. Thus, also from the point-of-view of 
logic programming, we extend the applicability of our previous work [BDMOO] 
(that was restricted to the propositional case) towards more interesting classes 
of linear logic programs. 



Plan of the paper. After introducing some notations in Section 2, in Section 3 
we present the language LO [AP90] enriched with constraints. In Section 4, we 
briefly review the approach we followed in [BDMOO], and we extend it to the first- 
order case. In Section 5 we discuss the connection between LO fixpoint semantics 
and the reachability algorithm for Timed Petri Nets presented in [AJ99]. Finally, 
we discuss related work and conclusions in Sections 6 and 7. The proofs of all 
results are in the extended version of the paper [BDMOOaj. 
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2 Preliminaries and Notation 

In this paper we will consider first-order linear logic languages built upon a sig- 
nature E comprising a finite set of term constructors, a finite set of predicate 
symbols, and a denumerable set of variable symbols. We will denote term con- 
structors by a,b, . . . , f, g, . . predicate symbols hy p,q,r, . . and variables by 
X,Y, Z, . . .. The set of (possibly non ground) atoms over E will be denoted Ajj. 
We will use to denote multisets of (possibly non ground) atoms. 

We denote a multiset A with (possibly duplicated) elements A^,. An by 
{^ 1 , . . . , A„} or simply Ai, . . . ,An if this notation is not ambiguous. A mul- 
tiset A is uniquely determined by a finite map Occ from As to the set of 
natural numbers, such that Occ^(A) is the number of occurrences of A in A. 
The multiset inclusion relation is defined as follows: A =4 B iff Occ^(A) < 
Occfi(A) for every A. The empty multiset is denoted e and is such that Occ^{A) = 
0 for every A (clearly, e ^ for any A). The multiset union A,B (written 
A + B when is ambiguous) of A and B is such that Occ^,b(A) = Occ_a,{A) + 
Occis{A) for every A. The multiset difference ^ \ K is such that Occ_ 4 \g(A) = 
max{Q,Occj({A) — Occs(A)) for every A. Finally, we define an operation • to 
compute the least upper bound of two multisets with respect to =^. Namely, A»B 
is such that Occj,,b{A) = max{Occj^{A) ,O ccb{A)) for every A. 

In the rest of the paper we will use A,0,. . . to denote multisets of possibly 
compound formulas. Given two multisets A and 0, A =4 0 indicates multiset 
inclusion and A, 0 multiset union, as before, and A, {G} is written simply A, G. 
In the following, we will refer to a multiset of goal-formulas as a context. Given 
a linear disjunction of atomic formulas H = Ai ^ . . . ^ A„, we also introduce 
the notation H to denote the multiset Ai, . . . , A„. 

3 The Language LO Enriched with Constraints 

TO [AP90] is a logic programming language based on a fragment of linear logic 
defined over the linear connectives o-, & , ^, and T. In this paper we will present 
a first-order formulation of LO using constraints. We will use constraints as a 
means to represent concisely collections of ground program clauses defined over 
a parametric interpretation domain. 

Constraints. Let V be a denumerable set of variables. In this paper a constraint 
is a conjunction (in the ‘classical’ sense) of atomic predicates ci A ... A c„, 
where c, has variables from V. The interpretation domain V of the constraints is 
fixed a priori. As an example, linear arithmetic constraints are conjunctions of 
inequalities of the form k\Xi + . . . +knXn op k, where ki is an integer constant, 
Xi is a variable that ranges over integer (real) numbers for alH : 1, . . . ,n, op 
is one operator taken from <,>,<,>,=, and k is an integer constant (e.g., 
2X + 3X >lAW>0Ay>0). An evaluation is an assignment a which maps 
variables in V to values in V. We denote the result of applying an evaluation a 
to a constraint c by <t(c). A solution for a constraint c is an evaluation a such 
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that (t(c) is true. Note that values assigned to variables which do not appear 
in c can be disregarded. For instance, any evaluation which maps X to 0.5, 
y to 2 and Z to 1.7 is a solution for the constraint (over the real numbers) 
X <1AY>2AZ>1. We call Sol{c) the set of solutions of c. In this paper 
we will always consider a constraint language with equality, so that t\ = t 2 is 
always defined for any expression This property ensures that it is always 

possible to express unification constraints. Given two constraints ci and C 2 , we 
define 

Cl entails C 2 if and only if Sol{c\) C Sol{c 2 ) 

(e.g. X = 2 entails X > 2). In this paper we will limit ourselves to consider 
domains in which the relation entails is decidable, and there are two constraints 
true and false such that c entails true, and false entails c for any c. 

Multisets Unifiers. Let .4 = pi(xi), . . . ,p„(x„) and K = gi (yi), . . . , g„(yn) 
be two multisets of atomic formulas such that Xj and yi are vectors of variables 
(distinct from each other) for i : 1, . . . ,n. If p, = g, (and they have the same 
arity) for i : 1, . . . , n, then the two multisets are unifiahle. The resulting unifier 
will be the constraint xi = yi A . . . A x„ = y„. Since the order of atoms inside 
a multiset does not count, there can be more than one way for two multisets 
to be unified. In the following, we will use the notation A = B to denote one 
constraint which is non- deterministically selected from the set of unifiers of A 
and B. If there are no permutations of one of the two multisets such that the 
previous conditions are satisfied, then A = B will denote the constraint false. 
Finally, in case n = 0 we have the constraint e = e which stands for true. 

LO Programs. We first define a goal formula via the following grammar. 

G :■.= G ^ G \ G k G \ p(x) | T. 

Here x is a vector of variables from the set V. An LO program with constraints 
consists of a set of universally quantified formulas having the following form: 

Ai G □ c, 

where n > 1, A, = pj(xj) for i : 1, . . . ,n, and Xj is a vector of variables in V, 
G is a goal formula, and c is a constraint whose scope extends over the whole 
implication Ai ^ . . . ^ A„ o- G. Note that we assume that all compound 
terms occur in c. For instance, using constraints we would write the first-order 
LO clause p{f{X)) o- q{X) as p{Y) o- q{X) n Y = f{X). Given a constrained 
expression F □ c (F can be a clause, a goal, a multiset of atoms, etc.) we define 

Gnd{F □ c) = {cr(F) | cr G Sol{c)}. 

We say that A G Gnd{F □ c) is an instance of F □ c. The definition can be 
extended to sets of expressions in the canonical way. Thus, given a program 
P, Gnd{P) denotes the set of all instances of clauses in F. Furthermore, note 
that a G-formula by itself is not very interesting, whereas constrained goals like 
p{X) & q{Y) n X — Y > 1 are the counterpart of the goals of Constraint Logic 
Programming [JM94]. 
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P^Gi,G2,A P^Gi,A P^G2,A 

T, % kr 

P^T,A P^Gi^G2,A P^Gi&lG2,A 

P^G,A 

be provided H o- G € Gnd{P) 

P^ H, A 

Fig. 1. Proof system for LO. 



Example 1. Let C = p{X,Y) ’^q{Z) o— t{Z,Y) d X = f{Z). If we interpret 
constraints over the term algebra {a, f{a), . . then p{f{a),a) ’^q{a) o- t{a, a) 
G Gnd{C). 

Top-down Ground Semantics. We define the top-down operational semantics 
of LO with constraints using the uniform (goal-driven) proof system of [AP90], 
presented in Fig. 1. As said at the beginning of this section, we introduce con- 
straints just as a convenient means to represent sets of ground clauses, therefore 
the proof system of [AP90] is sufficient for our purposes. In Fig.l, P is a set of im- 
plicational clauses, A denotes a multiset of atomic formulas, whereas A denotes 
a multiset of G-formulas. A sequent is provable if all branches of its proof tree 
terminate with instances of the axiom. The proof system of Fig. 1 is a spe- 
cialization of more general uniform proof systems for linear logic like Andreoli’s 
focusing proofs [And92] , and Forum [Mil96] . The rule he denotes a backchaining 
(resolution) step. Note that he can be executed only if the right-hand side of the 
current LO sequent consists of atomic formulas. Thus, LO clauses behave like 
multiset rewriting rules. LO clauses having the form Ff o- T □ c, where c is a 
satisfiable constraint, play the same role as the unit clauses of Horn programs. In 
fact, a backchaining step over these clauses sueeeeds independently of the current 
context. This observation shows that the weakening rule is admissible in LO, 
i.e., if P Zi is provable, then P A' is provable for any A ^ A' . Finally, the 
sueeess set or operational semanties of a (ground) LO program P is defined as 

\ A is a ground multiset and P => A is provable}. 

Remark 1 (Interpretation of eonstraints and □ in Linear Logie.). At least in 
principle, it seems possible to model constrained LO clauses inside linear logic 
itself. For this purpose, however, we need fragments larger than LO. In presence 
of the connective the constrained LO formula 

P o- G □ Cl A . . . A c„ 

could be represented as the linear logic formula 

H {G ® (ci ® ® c„)), 

while provability of constraint formulas could be expressed using a specialized 
(linear logic) theory. 
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Bottom-Up Ground Semantics. In [BDMOO], we have defined a ground 
fixpoint semantics based on a new fixpoint operator Tp for LO programs. We 
recall here the main ideas (see [BDMOO] for the details). Given a finite alphabet 
of propositional atoms (symbols), the (ground) Herbrand base Bp is defined as 

Bp = {A I .4 is a ground multiset of atoms in P}. 

We say that I C Bp is a Herbrand interpretation. Herbrand interpretations form 
a complete lattice wrt set inclusion. Satisfiability of a context (i.e. a multiset of 
goals) Zi in a given interpretation I, is defined via the judgment I \= A[A]. 
Let us assume that 7 is a set of provable multisets. Then, the output A of the 
judgment I |= A[A\ is any multiset of resources such that Zi + .4 is provable. 

Definition 1 (Ground Satisfiability). Let I C Bp, then \= is defined as 
follows: 

I \= T,.4[zl^] for any ground multiset A'; 

I \= A[A'] if A + A' £ I] 

7^Gi ^G2,A[A] ifI\=Gi,G2,A[A]; 

I\=GikG 2 ,A[A] j/7 |=Gi,Zi[.4] and I \= G 2 , A[A]. 

Given a program B, the operator Tp for constrained LO programs is defined as 
follows: 

Tp(7) = {H + A\ Hc^G£ Gnd{P), I \= G[.4]}. 

The fixpoint semantics, defined as the least fixpoint of Tp, is sound and complete 
with respect to the operational semantics, as stated in the following theorem. 

Theorem 1 ([BDMOO]). For every LO program P, 0(P) = lfp(Tp). 

4 Towards an Effective Non-ground Semantics 

The bottom-up ground semantics for first-order LO is not effective for two dif- 
ferent reasons: there might be possibly infinite instantiations of a constrained 
LO clause (this makes the condition 77 o- G € Gnd{P) not effective); there 
are infinitely many output contexts in a satisfiability judgment (this makes the 
computation of 7 j= Zi [.4] not effective). In [BDMOO], we have shown how to 
circumvent the second problem in the propositional case. 

Propositional Case. By exploiting the fact that weakening is admissible in 
LO, in [BDMOO] we noted that a provable multiset A can be used to implicitly 
represent the set of provable multisets Up{A) = {B j .4 B} where is multiset 
inclusion, i.e., Up{A) is the ideal generated by A wrt =^. As in the ground se- 
mantics, interpretations are still collections of multisets, however the denotation 
of an interpretation 7 becomes now |7] = U^g/ Up{A). Since multiset inclusion 
is a well-quasi ordering [ACJT96], the termination of the fixpoint computation 
is guaranteed by choosing the following pointwise ordering of interpretations: 
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Note that, A ^ B implies Up{B) C Up{A), whereas I Q J implies |/] C |J], 
The property of being a well-quasi order can be lifted from to C. Based on 
this observation, it is possible to define an effective operator whose fixpoint 
is computable in finitely many steps (see [BDMOO] for its definition). In the 
following section we will lift these ideas to first-order programs. 

First-Order Case. In view of our main goal (the definition of an effective 
fixpoint semantics for first order LO), we first define a new notion of Herbrand 
interpretation based on the notion of constrained multiset. Constrained multisets 
will be our symbolic representation of sets of ground multisets. A constrained 
multiset .4 □ c is a multiset of atomic formulas A whose free variables are 
constrained by c, e.g., like p{X),q{Y) Cl X >Y (Note that the whole multiset 
is in the scope of the constraint) . Variables which appear in c but not in A are 
implicitly considered existentially quantified, i.e. for instance p(X),q(Y) C X > 
Y A V = Z is logically equivalent to p{X),q{Y) □ 3Z.{X >Y AY = Z). In the 
following, we will use M, N, ... to denote constrained multisets. Now, we extend 
the ideas used in the propositional case as follows. A constrained multiset M 
defined as .4 □ c will represent the collection of provable goals that satisfy at 
least the constraint (wrt the multiset component A and the constraint part c) 
imposed by M. Formally, 

[-4 □ c] = Up(Gnd(A □ c)), 

the denotations are defined by taking first all instances of .4 □ c, and then (as in 
the propositional case) taking their upward closure wrt =^. As an example, the 
denotation (over the real numbers) of M = {p{X),q{Y)CX > Y) contains both 
{p(l),g(0)} and {p(l), g(0), g(9)}, since they both satisfy at least the constraint 
in M. We are now ready to define the new notion of interpretation. 

Definition 2 (Extended Herbrand Base and Interpretations). The ex- 
tended base is defined as Bp = {ACc\A is a multiset of atoms p(x), c is a 
constraint }. I C Bp is called extended Herbrand interpretation and 

|71 = (J 1^ □ c]. 

(.4 □ c)ei 

Definition 3 (Lattice of Interpretations). The lattice (T, C) of extended 
Herbrand interpretations is defined as follows: 

— I = V(Bp)l ~ where I ~ J if and only if [/] = [Jl; 

— [I]c^Q [•/]- if and only if [7] C [,/]; 

— the bottom element is the empty set 0, the top element is the ^-equivalence 
class of the singleton {(e □ true)}; 

— the least upper bound I U J is the ^-equivalence class of I U J. 

The equivalence ~ allows us to reason modulo redundancies. For the sake of sim- 
plicity, in the rest of the paper we will identify an interpretation I with its class 
[7]^. In the following, we will lift the fixpoint semantics from the propositional 
to the first-order case using the new notion of interpretation. To this aim, we 
will first need an effective notion of satisfiability wrt an interpretation. 
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4.1 Effective Satisfiability Test 

To decide if a given constrained goal G □ c is satisfiable in the extended interpre- 
tation I, we must extend the judgments used in the propositional case in order 
to handle the constraint components. Since G may contain nested occurrences 
of connectives, it might be necessary to decompose G into a multiset of atoms 
A and then match A against I. The last step may introduce new bindings for 
the variables in G. We must return these bindings in form of constraints, since 
they will be used when incorporated in the backward application of a clause 
H o- G (e.g., whenever H and G share common variables). For this purpose, 
we introduce the new judgment 

7 Ih G [C ; c] 

where G is a constrained goal (later extended to a constrained multiset of goals) , 
C is the output multiset (as in the propositional case) and c is the output con- 
straint. The judgment 7 Ih G [C ; c] should return in C a representation of all 
possible multisets which, added to G, make it provable (under the constraint c). 
Based on the previous intuition, we will formally define the satisfiability relation 
as follows. In the following the notation G,Zi □ c must be read as (G,A) □ c. 

Definition 4 (Non-gronnd Satisfiability Relation Ih). Let I £ T, then Ih 
is defined as follows: 

ALL 7 Ih T,.4 □ c [e ; c]; 

PAR I \\- G\ G2, A U c [C ] c'] if and only */ 7 Ih Gi , G 2 , 4 i □ c [C ; c']; 

MULT 7 Ih .4 □ c [C ; c'] if and only if there exists a renamed eopy B O d 

of an element of I, B' B, and .4^ .4 sueh that 

c' = B' = A' A c A d is satisfiable, and C = B \ B' ; 

WITH 7 Ih Gi & G 2 , 4i □ c{C ; c'] if and only if I \\- G\, A □ c [ Ci ; ci], 

7 Ih G2,A □ c [ C2 ; C2], and there exist C\ C\, C'2 C2, sueh that 

c' = C\ = C'2 Ac\ Ac 2 is satisfiable, and C = Ci + {C2 \ €'2). 

The above definition is entirely algorithmic. Given an interpretation and a con- 
strained goal G (a multiset of goals, in general), the set {(C, c) | 7 Ih G [C ; c]} 
is always finite. Rules par and all should be clear. In rule with, given the 
output context Ci □ ci and C 2 □ C 2 for the two conjuncts, the output context 
for Gi &G 2 is obtained by merging in all possible ways sub-multisets of Ci and 
C 2 that are unifiable. Rule mult is for goals consisting of a constrained multiset 
.4 □ c of atomic formulas. If A contains a sub-multiset unifiable with a sub- 
multiset B' of an element B oi I, B\B' is the minimal context to be added to 
.4. 

Example 2 . Consider a language over the term universe {a, /(a), . . .}, let G be 
the goal {q{X) ^r(T)) & s{Z) d Z = a, and 7 be the interpretation consisting 
of the two constrained multisets 

Ml =t( 7 /i,Ri),g(Wi) □ Ui= f{Qi)AWi=a, 
M2=t(U2,V2),s(W2) □ V2 =f(Q2)AW2 =a. 
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Using the with rule, we have to compute Ci,C2,ci,C2 such that I Ih q{X) ^ 
r(y) O Z = a [Cl ; ci] and I Ih s(Z) O Z = a [C2 ; 02]- For the first conjunct 
and using the par rule, we have that I Ih q(X) ^ r(Y) D Z = a [Ci ; ci] iff 
I Ih q{X),r{Y) n Z = a [Cl ; ci]. By mult rule, applied to Mi € I, we have 
that Cl = t(Ui,Vi) and ci = X = Wi KWi = a A Z = a AUi = f{Qi). For 
the second conjunct and using the mult rule applied to M2 G I, we have that 
C2 = f(U2, V2) and C2 = ^ = W2 A Z = a A W2 = a AV2 = f{Q2)- Therefore 
by definition of the with rule, if we unify t{Ui,Vi) and t(U2, V2), we have that 

7 Ih G [t{Ui,Vi) ; [7i = 7/2 A Vi = U2 A Cl A C 2 ]. 

More concisely, by renaming the variables, we get I \\- G [t{U,V) ] X = aA Z = 
a AU = f{Q) AV = We also have, by choosing empty sub-multisets in 

WITH rule, that 

7lhG [t(7/i,Ui),t(7/2,U2) ; Cl Ac2]. 

More concisely, by renaming the variables, we get 7 Ih G [t(77, V),t{U' ,V) ; X = 
aAZ = aAU = f{Q) AV' = 



4.2 Effective Fixpoint Semantics 

Based on the previous definitions, we can define a fully symbolic fixpoint operator 
Sp for LO programs with constraints. The operator Sp transforms extended 
interpretations in extended interpretations as follows. 

Definition 5 (Fixpoint Operator Sp). Given an LO program P , and 7 G T, 

Sp(I) = { 77 -H C □ c') I 3 (77 o- G □ c) variant of a 

clause in P s.t. I \\- G O c [C ] c'] } 

Proposition 1. Sp is monotonic and continuous over the lattice (T, C). 

Then, we have the following results. 

Proposition 2. Let P be a constrained LO program, and I G T. Then, |5'p(7)] = 
TGnd{P){m) ■ 

Corollary 1. [lfp(Sp)l = lfp{TGnd(P)) ■ 

Let SymbF(P) = Ifp(Sp). Then, we have the following main Theorem. 

Theorem 2 (Soundness and Completeness). Given a constrained LO pro- 
gram P, Oand(P) = lSymbF(P)l. 

Though a single application of the operator 5p is effective, in general it might 
be impossible to compute the fixpoint of Sp (first-order LO programs are Turing 
complete). We can make a similar observation for the non-ground operator Sp 
of Constraint Logic Programming [JM94]. 
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Example 3. Consider the clause p(X) ’^p{Z)o-{q{X) '^r{Y)) & s{Z) d Z = a, 
and the interpretation I of Example 2. Let G = (g(X) ’^r{Y)) & s{Z) U Z = a. 
From Example 2, we know that 7 Ih G [t(U, V) \ X = aKZ = aKU = f{Q)AV = 
f{Q')] and 7 Ih G [t{U, V),t{U' ,V) ■ X = aAZ = aAU = f{Q) AV' = f{Q')]. 
Thus, we get that Sp{I) contains 

p{X),p{Z),t{U, V)UX = aAZ = aAU = f(Q) AV = f(Q'), 
p{X),p{Z),t{U, V),t{U',V) a X = aAZ = aAU = f{Q) AV' = f{Q'). 

As particular instances, we have that Sp{I) includes (representations of) the 
multisets p{a) , p{a) , t{f{a) ,f{a)) and p{a) , p{a) , t{f{a) , a) , t{a, /(a)) • This exam- 
ple shows the importance of maintaining all constraints generated during an 
evaluation of a judgment (e.g. X = a m the first case). In fact, the scope of 
these constraints extends over the atoms in the head of clauses (e.g. p{X)). 

5 Relationship with Timed Petri Nets 

We will illustrate the main ideas of the connection between our fixpoint seman- 
tics and the framework of [AJ99] to decide reachability problems for Timed Petri 
Nets. As explained in the introduction. Timed Petri Nets (TPNs) are infinite- 
state networks where tokens move from place to place (place=node of the net) 
carrying along their age. TPN transitions have two possible forms. Discrete tran- 
sitions specify how tokens move around the network, whereas timed transitions 
simply increase the age of every token in the network. The results of [AJ99] are 
based on a symbolie representation of potentially infinite sets of TPN configura- 
tions (i.e. tokens with their age) via existential regions. An existential region is 
a formula having the following form 

3xi . . .3Xn- P(xi,...,Xn) and c(xi,...,Xn) 

whose meaning is as follows: there exist at least n distinct tokens distributed in 
the network as deseribed by formula P and whose ages satisfy the eonstraint c. 
The formula P is a conjunction of constraints of the form Xj € Pi, whose meaning 
is the token Xj is in plaee pi. In the interpretation domain existentially quanti- 
fied variables are required to denote distinet values. The constraint c is a eloek 
eonstraint [AJ99], i.e., a conjunction of atomic predicates like Xi —Xj < k (where 
k is an integer constant) , which expresses a bound on the difference between the 
clock values of different tokens. More simple constraints like Xi < k or Xi > k, 
which limit the clock value of a single token, can be seen as subcases of the 
previous class of constraints. An existential region # denotes an upward elosed 
set of TPN configurations (i.e. those satisfying at least the constraints in #). 
Based on this construction, the algorithm of [AJ99] solves the following type of 
reachability problems. 

Control state reachability: given an initial configuration 7 q and an existential 
region #, is it possible to reaeh a configuration in (the denotation of) # 
starting from (an instance of) 7 q? 
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The algorithm works as follows. It computes the effect of applying backwards the 
transitions of the TPN starting from until it reaches a fixpoint F. As a last 
step, it checks if [/oln[F] = 0. The termination of the algorithm is guaranteed by 
the following properties: existential regions are well-quasi ordered [AJ99,AN00]; 
the class of existential regions is closed under backward applications of TPN 
transitions, i.e., if we apply backwards TPN transitions to a set of existential 
regions we still obtain a set of existential regions. Instead of entering in more 
details in the TPN formalism, we immediately show how the discrete components 
of TPNs can be modeled via TO programs. 

TPNs as First-Order Linear Logic Theories. First of all, a token in place 
p and age n can be represented as the atomic predicate p{n). Thus, discrete 
transitions can be represented via TO clauses of the form: 

Pl(Xi) ^ ... ^ Pn(Xn) ^ qi(Yi) ^ ... ^qm(Y^)ac 

where Pi,qj are place names and Xi,Yj are variables associated to the ages, and c 
is a constraint over the age of tokens. Specifically, c specifies the constraint under 
which the tokens can be removed from pi, ... ,pn, and the new constraint on the 
ages of the tokens added to qi, ... ,qm- Timed transitions cannot be represented 
directly in LO. This encoding can be done via a meta-rule 

P^Pl(Xi+S),...,Pn(Xn+S) 

Time {S > 0) 

P ^Pl(Xi),...,Pn(Xn) 

whose definition in Linear Logic (e.g. in Forum [Mil96]) requires giving & family 
of clauses, using the constant 1 to ensure that the age of every token in the 
network is incremented as a result of a timed transition. In contrast with T, 
1 succeeds only in the empty context. The semantics for LO presented here 
could be extended, similarly to what done in the propositional case [BDMOO], to 
include the constant 1 . Anyway, as far as the application to TPNs is concerned, 
in [AJ99] the authors show how to compute effectively the backward application 
of timed transitions (i.e. our meta-rule) on a given existential region. We skip 
therefore a detailed discussion about encoding timed transitions in LO. We can 
use the ideas of [AJ99] provided we find a counterpart of existential regions in the 
LO setting, and provided we can find a way to connect a backward reachability 
step with the LO operational semantics. 

Existential Regions as Constrained Mnltisets. Existential regions can be 
naturally represented as constrained multisets having the following form: 

Pi{Xi), . . . ,p„{X„) □ c 

where c is a constraint. In fact, the denotation |A □ c] of a constrained multiset 
.4 □ c, captures precisely the intended meaning of the existential regions of 
[AJ99]. As an example, lp{X),q{Y) — y<l] = {{p(l), g(0)}, {p(l), 

g(0),g(3.6)},...}. 
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Backward Reachability = Bottom-Up Evaluation. At this point, it should 
be clear that computing the effect of a backward application of the transitions of 
a TPN N coincides with computing an application of the operator associated 
to the LO program encoding N. In order to start up the bottom-up evaluation 
from the set of configurations represented by the target existential region we 
simply have to add the clause: pi{Xi) ^ ^ Pm{Xm) o- T □ c where 

= 3xi, . . -Xm- x\ e Pi and . . . and Xm G Pm <md c. Through this encoding, 
we automatically inherit from [AJ99] the following property. 

Theorem 3. Let N be a TPN, <P an existential region, and Pn be their eneoding 
in LO enriehed with the meta-rule for timed transitions. Then, SymbF(PN) is 
eomputable in finitely many steps. 

Besides the basic multiset rewriting mechanism, the linear logic language LO 
provides other connectives that add further expressiveness to the operational 
reading of specifications. For instance, we give some hints about using the addi- 
tive conjunction & to specify an operation to hierarchically compose TPNs. If 
we think about TPNs as representing the execution of some kind of protoeol, the 
rule p{X) o- pi{Xi) & p^iXfi) □ c could be seen as the specification that the 
protocol p will start (at the time specified by c) two sub-protocols that must suc- 
ceed in order for p to succeed. The subsystems p\ and p 2 will run independently. 
Since clock constraints are closed under conjunctions, the result of Theorem 3 
can be extended in order to include LO programs with conjunction as the one 
in the previous example. 

6 Related Works 

To our knowledge, our work is the first attempt to connect algorithmic techniques 
used in symbolic model checking with declarative and operational aspects of 
linear logic programming. In [BDMOO], we have considered the relation between 
propositional LO and Petri Nets. In this paper we have extended the connection 
to first-order LO programs and more general notions of Petri Nets. 

In [HW98], Harland and Winikoff present an abstract deductive system for 
bottom-up evaluation of linear logic programs. The left introduction plus weak- 
ening and cut rules are used to compute the logical consequences of a given 
formula. Though the framework is given for a more general fragment than LO, 
it does not provide for an ejfeetive procedure to evaluate programs. 

Finally, in [Cer95] Cervesato shows how to encode Petri Nets in LO, Lolli and 
Forum exploiting the different features of these languages; whereas in [APC93], 
Andreoli, Pareschi and Castagnetti define an improved top-down strategy for 
propositional LO based on the Karp-Miller’s coverability tree of Petri Nets, i.e., 
a forward exploration with accelerations. 

7 Conclusions and Future Work 

In this paper we have investigated the connections between techniques used 
for symbolic model checking of infinite-state systems [ACJT96,AJ99,FS98] and 
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provability for first-order linear logic programs [AP90] . We have generalized the 
construction used in [AJ99] to decide verification problems for Timed Petri Nets 
in order to build an effective fixpoint semantics for first-order LO programs. Ad 
hoc notions like the existential regions of [AJ99] find a natural counterpart as 
elements of the non-ground interpretations of LO programs, a notion inspired by 
the more advanced semantics of Constraint Logic Programming [GDL95,JM94]. 
Furthermore, we have shown that the algorithms used for (Timed) Petri Nets 
can be extended in order to capture the richer specification language LO. 

The main interest of the new semantics is that it gives us a way to evaluate 
bottom-up first-order LO programs, i.e., an alternative operational semantics 
that could be useful to study new applications of linear logic programming (as 
discussed in [HW98]). For this reason, we think it would be important to extend 
our method to other linear logic languages like Lolli [HM94] and Forum [Mil96] . 

The work presented in this paper can also be a source of further investiga- 
tions concerning the analysis of programs and the development of new observable 
semantics. In particular, the semantics could be extended in order to cope with 
observables like the non ground success set and computed answer substitutions 
[FLMP93] of LO programs. To this aim, we plan to formulate the constraint- 
based semantics presented here using a more traditional approach based on sub- 
stitutions and most general unifiers. While the constraint-based formulation was 
particularly suitable to study the connection with TPNs, a formulation based 
on substitutions could be useful for extending traditional program analysis tech- 
niques to linear logic programs. 

Acknowledgments. The authors would like to thank Iliano Cervesato and the 
anonymous reviewers for their useful comments and suggestions. 
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Abstract. In this paper we start the design of a functional-logic de- 
ductive database language. Given that most logic deductive languages 
consider bottom-up evaluation as operational mechanism, here we will 
focus on the development of an operational semantics based on bottom- 
up evaluation for functional logic languages. As in the logic paradigm, 
the bottom-up evaluation will consist in a magic transformation for a 
given program-query into a magic program-query for which the bottom- 
up evaluation will simulate the top-down one of the original program. 



1 Introduction 

Deductive databases are database management systems whose query language 
and, usually, storage structure are designed around a logical data model. It 
is easy to see deductive database systems as an advanced form of relational 
systems, and they are best suited for applications in which a large amount 
of data must be accessed and complex queries must be supported. Deductive 
databases languages [21] have been influenced by work in logic programming and 
offer a rich query language, which extends SQL in many important directions 
(including support for aggregation, negation, and recursion). Deductive databases 
languages use logic programming concepts but do not share in most cases the 
evaluation mechanism of traditional logic programming languages as Prolog. 
There are three main reasons for it: 

— Prolog’s depth-first evaluation strategy leads to infinite loops, even for defi- 
nite programs and even in the absence of function symbols or arithmetic. In 
the presence of large volumes of data, operational reasoning is not desirable, 
and a higher premium is placed upon completeness and termination of the 
evaluation method. 

— In a typical database application, the amount of data is sufficiently large that 
much of it is on secondary storage. Prolog systems evaluate logic programs 
efficiently in main-memory, but are tuple- at- a-time; that is, they process 
one (sub) goal at a time, and thus inefficiently w.r.t. disk accesses. Efficient 
access to these data is crucial to good performance. 

— When evaluating a database query, it is customary to want to compute all of 
the answers to the query. When writing a program for computation purposes, 
such as a typical Prolog program, it is common to only need one answer to 
the query. 
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One consequence of this is that most deductive database systems (for instance, 
DATALOG [25], CORAL [20], ADITI [26]) use bottom-up evaluation methods 
instead of top-down one. Bottom-up approach allows us to use set-at-a-time 
evaluation, i.e. it processes sets of goals, rather than proceeding one (sub) goal 
at a time, where operations like relational joins can be made for disk-resident 
data efficiently. In this sense, deductive systems are an attempt to adapt Prolog, 
which has a “small-data” view of the world, to a “large-data” world. On the 
other hand, the bottom-up evaluation avoids infinite loops over programs under 
certain conditions. 

An important problem is that a query asks not for the entire relation cor- 
responding to an intensional predicate but for a small subset. It is important 
that we answer a query by examining only the part of database that involves the 
predicates relevant to the instantiated or partially instantiated arguments in the 
query. The goal-directed bottom-up evaluation generates the subset of the Her- 
brand model of the program relevant to the query. With this aim, the bottom-up 
evaluation in such languages involves a query-program transformation termed 
Magic Sets [5]. 

The basic idea of this technique is that a logic program-query is transformed 
into a magic logic program-query whose bottom-up fixed point evaluation [3] is 
devised to simulate top-down evaluation of the original program and query. The 
program is evaluated using bottom-up evaluation until no new facts are gener- 
ated or the answer to the query is found. The transformed program adds new 
predicates, called magic predicates, whose role is to pass information (instanti- 
ated and partially instantiated arguments in the predicates of the query) to the 
program in order to consider only those instances of the program rules relevant 
to the query solving. 

Example 1. Given a set of facts for a relation par and the following logic rules: 
anc(X,Y) :-par(X,Y) . 

Einc (X, Y) : -par (X,Z) , Emc (Z , Y) . 

and a query anc(john,X), the magic-sets transformation rewrites this program 
into the following logic program: 

Einc (X, Y) : -mg_anc (X) ,par (X, Y) . 

Einc (X, Y) : -mg_anc (X) ,par (X, Z) ,anc (Z, Y) . 
mg_anc(Z) : -mg_anc (X) ,par(X,Z) . 
mg_anc(john) . 

together with par(a,/3) : -mg_par (a,/3) for each pair a, fi in the relation par. 
The fixed point evaluation computes only the ancestors of John (and those in- 
termediate results needed for it). 

Several transformation magic methods have been widely studied in the past 
with the aim to deal with recursive queries, non-ground facts, function sym- 
bols, partially instantiated terms, negation and to provide optimizations such as 
avoiding the computation of duplicated facts, and the memoization of interme- 
diate results. 

As examples, we have the transformations called Generalized Magis Sets [5, 
12], Generalized Supplementary Magic Sets [5], Magic Templates [19], Alexander 
Templates [24], Counting Methods [23] and recently Induced Magic Sets [6]. 
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Although bottom-up evaluation based on magic-sets has been studied in the 
context of logic programming, there are some approaches (for instance [13]) 
which consider bottom-up evaluation of constraint logic programs, showing a 
new research area in the application of the CLP scheme for databases in the 
framework of constraint query languages [11]. Moreover, the bottom-up eval- 
uation has been used in the context of semantic-based program analysis (for 
instance [4]). 

Deductive databases have also been studied in a functional programming 
context (PPL [22], FDL [18]), enjoying the three following advantages, ease of 
reasoning: the reasoning can be used to transform queries into a more efficient 
form or to prove that transactions preserve consistency constraints; freedom from 
a detailed execution order, this freedom has been used to improve query evalu- 
ation by selecting an appropriate execution order for subqueries, in such a way 
that this freedom makes parallel execution natural in functional database query 
languages; and freedom from side-effects: because side-effects may not be antici- 
pated by the programmer, they complicate the programmer’s task, especially in 
large database applications. 

On the other hand, the integration of functional and logic programming has 
been widely investigated during the last years, see [8] for a survey. It has leaded 
to the recent design of modern programming languages such as CURRY [9] and 
Toy [16] following the ideas of the predecessors BABEL and K-LEAF. The 
aim of such integration is to include features from functional (cfr. determinism, 
higher order functions, partial, non strict and lazy functions, possibly infinite 
data structures) and logic languages (cfr. logic variables, function inversion, non- 
determinism, built-in search). The basic ideas in functional- logic programming 
consist in lazy narrowing as operational mechanism, following some class of nar- 
rowing strategy [2, 14] combined with some kind of constraints solving [15] and 
higher order features [10]. 

The aim of this paper is to study a functional-logic deductive database lan- 
guage. Given that most logic deductive languages consider bottom-up evaluation 
as operational mechanism, here we focus on the development of an operational 
semantics based on bottom-up evaluation for functional logic languages. As in 
the logic paradigm, the bottom-up evaluation will consist in a magic transfor- 
mation for a given program-query into a magic program-query for which the 
bottom-up evaluation will simulate the top-down one of the original program. 

With respect to logic programming paradigm, we have to solve the old and 
new problems. In the earliest logic deductive databases, logic programs were 
constrained to be free of function-symbols, facts were grounds and deduction 
rules were well-formed, i.e. each variable that appears in the head of the rule 
also appears in its body [5] . These conditions ensure termination of the bottom- 
up evaluation based on magic-sets given that the least Herbrand model [3] is 
finite in the original and magic program, and thus bottom-up is a complete 
deduction procedure whereas Prolog is not. 

Example 2. In the following logic program: 
p(X) :-p(X) . 

p(0) . 
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the Prolog solving of the goal p(0) loops and no answer is found, however the 
bottom-up does not; the evaluation of the transformed magic program: 
p(X) : -mg_p(X) ,p(X) . 
p(0) : -mg_p(0) . 
mg_p(0) . 

where mg_p is the magic predicate associated to p, ends and obtains p(0) as fact. 

Later [19], the well-formed condition was removed but no general result of ter- 
mination for bottom-up evaluation was presented by allowing function-symbols 
(and therefore for general Horn-logic programs), although some attempts were 
done [24, 19]. In the presence of function symbols, the Herbrand model of a logic 
program can be infinite and thus, in the general case, the bottom-up evaluation 
of the original and transformed program cannot end. Therefore, the introduction 
of function symbols causes uncompleteness for negative information. 

In summary, the main aims of such works were to find a bottom-up eval- 
uation method for restricted or general Horn-logic programs which simulates 
top-down evaluation, that is, a goal-directed and efficient evaluation method (in 
terms of intermediates facts (subgoals) that are generated [24,6]) which retains 
the advantages of avoiding infinite loops and set-at-a-time computations. They 
also study semantic models and magic transformations for deductive database 
languages with negation [12]. Thus, we may say that the bottom-up evalua- 
tion is better than top-down one w.r.t. positive goals: bottom-up evaluation is 
a complete deduction procedure when top-down is not. In the presence of func- 
tion symbols and negative goals, both bottom-up and top-down evaluation with 
negative goals are, in general, uncomplete procedures. 

In our case, we will consider a functional logic language like TOy [7], that is, 
our programs will be conditional constructor-based rewriting rules in which no 
additional restrictions in the form of program rules will be required. Therefore, 
Horn-logic programs will be considered as particular cases of our functional-logic 
programs. It means that we will have the same problems due to the introduc- 
tion of function symbols in deductive logic programs (called constructors in a 
functional-logic context). Given that in this paper we do not deal with nega- 
tion, we will now not care about it. We are interested in the definition of an 
operational semantics for T Oy programs based on bottom- up evaluation which 
simulates the top-down one of a T Oy program. This bottom-up evaluation will 
be as goal-directed as top-down evaluation, that is, it generates the same in- 
termediate results than the top-down evaluation, retaining the advantages of 
bottom-up evaluation. We will consider the standard magic transformation with 
left-to-right information passing strategy [5] . 

As new contributions of this paper, we have the dealing with functions instead 
of logic predicates, which can be lazy, partial and non-strict, and the dealing 
with possible infinite data, which introduces new problems in the bottom-up 
evaluation once we have to apply program rules lazily in every step of the fixed 
point operator application. The laziness of the evaluation will be driven by the 
goal evaluating program rules (arguments and conditions) as far as the goal 
requires. In this sense, our bottom-up evaluation is similar to the demand-driven 
[14] top-down evaluation of functional logic programs. As far as we know, this is 
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the first time that such kind of evaluation method for functional logic languages 
has been presented. To put an end to the comparison of bottom-up and top- 
down evaluations in our framework, we will establish the equivalence results 
of our bottom-up evaluation and the conditional rewriting logic (CRWL) [7] 
which provides logic foundations to the TOy language, and therefore ensuring 
soundness and completeness of our bottom-up evaluation. Moreover, we will 
establish correspondences among proofs of a given goal in the cited logic and the 
“facts” computed by means of the bottom-up evaluation showing the optimality 
of our evaluation method. 

The rest of the paper will be organized as follows. In section 2 we will in- 
troduce basic notions that will be used in the rest of the paper; in section 3 we 
present the language; the section 4 will define Herbrand models for our language; 
section 5 will present the magic transformation; section 6 will show the results of 
soundness, completeness and optimality and finally in section 7 we will describe 
the future work and conclusions. Due to the lack of space, the proofs of our 
results have not been included in this version but the full proofs can be found 
in [1]. 

2 Basic Notions 

We assume the reader has familiarity with basic concepts of model theory on logic 
programming and functional-logic programming (see [3, 17, 7] for more details). 
We now point up some of the notions used in this paper. 

Given S, a partially ordered set (in short, poset) with bottom T (equipped 
with a partial order < and a least element T), the set of all totally defined 
elements of S will be noted Def(S). We write C{S), T{S) for the sets of cones 
and ideals of S respectively. The set S =def 1{S) denotes the ideal completion 
of S, which is also a poset under the set-inclusion ordering C, and there is a 
natural order which maps each x € S into the principal ideal generated by x, 
< X >=def {y & S ■. y < x} £ S. Furthermore, S is an algebraic cpo whose finite 
elements are precisely the principal ideals < x >, x G S. 

A signature is a set ^ = C U iT, where C = Une w ^ ~ Une w 

disjoint sets of constructor and function symbols respectively, each of them with 
associated arity. Expr^ and Terms denote the set of expressions built up from 

and a set of variables V, and the subset of terms making only use of C and V, 
respectively. We distinguish partial Exprs^ (resp. Terms Y) and total expres- 
sions (resp. terms) depending whether they include T or not. The approximation 
ordering < for Terms± can be defined as the least partial ordering satisfying 
the following properties: T < f, for every t, and if ti < Si,...,tn < then 
c{ti, ...,tn) < c(si, ...,s„), for every c e C”. 

Substitutions are mappings 9 : V ^ Terms^^ which have 9 : Terms^ — > 
Terms ^ as unique natural extension, also noted as 9. Substs (resp. SubstsY 
denotes the set of substitutions in total (resp. possibly partial) terms. We note 
as t9 the result of applying the substitutions 9 to the term t. 

3 A Functional Logic Language 

A program V is a signature E together with a set of conditional constructor- 
based rewrite rules of the form: f{ti ,...,!„) := r C where f G E oi arity n, 
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t must be a linear tuple of terms U G Terms, and the condition C must consist 
of finitely many (possibly zero) of strict equalities e == e' with e, e' G Exprs- 
[V] = {{I := r ^ C) 6 \ {I := r ^ C) £ V , 9 G Substsj^} denotes the set of 
(possibly partial) instances of the program rules of P. We allow extra variables 
in the body and the condition. In fact, our rules can be used to dehne non- 
deterministic functions. A goal G is like the conditional part of a program rule. 

Now we present the semantics of a language through a conditional rewriting 
logic (CRWL) as in [7]. This logic allows us to prove statements of the form 
P ^cnwc e ^ t, with e G Exprs^,t G Terms^, called non-strict equalities, 
whose meaning is that term t approximates the value of the expression e, and 
strict equalities P y^enwc e == e' , e, e' G Exprs^ whose meaning is that e 
and e' represent the same totally defined value. A solution for a goal G w.r.t. a 
program "P is a substitution 9 G Substs^ such that P 'Gcnwc G9. The formal 
presentation of CRWL is as follows: 

Definition 1 (Conditional Rewriting Logic (CRWL)). 

(B) ^ ^ 

(R) r ^ e (DC) e„ ^ ^ ^ ^ 

c(ei, ... ,en)^c(ti, ... ,tn) 

(O) ^ C r-^t .gx — e_spl t G Terms 

f(ei, ... ,en)^t e == e 

t ^ ±, f{ti , ... , tn) ■= r C € [P] 

4 Herbrand Models 

4.1 CRWL- Algebras 

In this section we present Herbrand algebras and models as a particular case of 
CRWL-algebras. Firstly, we need the following dehnitions. 

Definition 2 (Non-deterministic and Deterministic Functions). Given 
two posets D and E with T we define: 

— The set of all non-deterministic functions from D to E as: 

[D E] =def {f:D^ C{E)\ ^ u,u' £ D : {u < u' ^ f{u) C f{u'))} 

— The set of all deterministic functions from D to E as: 

[D E] =def {f £[D^r.E]\\f u£ D : f{u) £ I{E)} 

Now we can define the class of algebras which will be used as models for CRWL: 
Definition 3 (CRWL- Algebras). For any given signature, CRWL-algebras 
are algebraic structures of the form: A = (Rq, {c^}c^c, {f^}f&J^) where is 
a poset, cA £ [D^ Dj\\ for c £ C^, and f^ G Djf\ for f G iF". For 

Cy{ we still require the following additional condition: for all u^, . . . ,Un £ 
there is v £ such that c^{uj , . . . , m„) =< v >. Moreover, v £ Def{DX) in 
case that all Ui £ Def(Djx) 

The next definition shows how to evaluate expressions in CRWL-algebras: 
Definition 4 (Expression evaluation). Let A be a CRWL-algebra of signa- 
ture A evaluation over A is any mapping rj :V ^ Pa, we say that rj is 
totally defined iff rj{X) £ Def{DA) for all X £V. We denote by Val{A) the set 
of all valuations, and by DefVal{A) the set of all totally defined valuations. The 
evaluation of e £ Expr^^ in A under p yields jef^r] £ C(Da) which is defined 
recursively as follows: 
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— 1-L1-^?7 =def< -Lyt >. 

— \Xj-^r]=aef<viX) >,forX€V. 

-\h{ei, ... ,en)l-^V=defh-^{\eil-^r], ... , |e„|-^?7), /or a// /i G C" U 
Due to non-determinism, the evaluation of an expression yields a cone rather 
than an element. However, this cone can still represent an element (in the ideal 
completion) in the case that it is an ideal. It can be proved that given a CRWL- 
algebra A, for any e G Exprsj^ and any rj G Val{A) then lef^r] G C(D^), lej-^r] G 
T{Dj\) if /-^ is deterministic for every defined function symbol / occurring in e, 
and le|-^?7 =< v > for some v G if e G Terms^^ and v G Def{DX) if e G 
Terms and rj G DefVal{A). Moreover, given a valuation over a CRWL-algebra 
A, for any e G Expr and any 9 G Subst we have = |e[-^ 770 , where pd is the 

uniquely determined valuation that satisfies < rj9{X) >= lX9j-^r] for all X G V. 

4.2 Herbrand Models 

Now we can introduce Herbrand models. The main ideas are to interpret non- 
strict equalities in A as inclusions among cones and to interpret strict equalities 
as asserting the existence of some common, totally defined approximation. 
Definition 5 (Models). Assume a program V and a CRWL-algebra A. We 
define: 

— A satisfies a non-strict equality e — > e' under a valuation rj (in symbols, 
(A,rj) e ^ e'; ifflej-^r] D le'|-^77. 

— A satisfies a strict equality e == e' under a valuation rj (in symbols, (.4, rj) |= 
e == e') iff\el-^r](]le'l-^'nf]Def{D^) 0. 

— A satisfies a rule I := r ■:= G iff every valuation r] such that {A,rj) \= C 
verifies: {A,rj) \= I ^ r. 

— A is a model ofV (in symbols, A\=V) iff A satisfies all the rules in V. 

Theorem 1 (Soundness). For any program V and any non-strict or strict 
equality <p: V Lcnwc T 1= for all A\^V and all tj G DefVal{A). 

Now we define Herbrand algebras as a particular case of CRWL-algebras in 
which the poset is the set of terms partially ordered by < and the interpretation 
of the constructors consists of the ideal generated for the represented term. 

Definition 6 (Herbrand Algebras). Given a program V, a Herbrand Algebra 
A is defined as follows. Dq the poset Terms^ with the approximation ordering 
< and c^{ti, ... fin) =def < c[ti, ... fin) > (principal ideal), for all f G 

Terms ^ . 

From now on Vain denotes the valuations in Herbrand algebras. 

Definition 7 (Poset of Herbrand Algebras) . Given a program V we define 
the poset CRWLH of Herbrand algebras as follows: A < B iff f^it\, . . . , t„) C 
/®(ti, . . . ,tn) for every / G X and fi G Termsj^, 1 < i < n. 

Moreover, we can prove that the ideal completion of CRWLH is a cpo, and | | 
is continuous w.r.t. the ideal completion of CRWLH and Vain- 
Definition 8 (Fix Point Operator). Given A G CRWLH , f G if, we define 
the fix point operator as: 

T-p{A,f){si,...,Sn) =def {M:^ I there exists f(t) — r^CeV, 
and tj G Val{A) such that iLj:^ = Si, {A,rj) ^ C} 
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Proposition 1. Given A G CRWLH there exists a unique B G GRWLH de- 
noted by T-p{A) such that . . . ,tn) = Tp{A, f){ti, . . . ,tn) for every f G tF 

and ti G Terms^, 1 < i < n. 

With these definitions, we can ensure the following result which characterizes 
the least Herbrand model. 

Theorem 2. The fix point operator T-p is continuous and satisfies: 

1. For every A G GRWLH: A\^V iffTp{A) < A. 

2. Tp has a least fix point Mp = where TLp^ is the bottom in 

GRWLH and np’^+^ = Tp{Ti.p'") 

3. Mp is the least Herbrand model ofV. 

Moreover we can see that satisfaction in Mp can be characterized in terms of 
^enwc provability. 

Lemma 1 (Characterization Lemma). Let id be the identity valuation over 
Mp, defined by id(X) = X for all X G V. For any non-striet or striet equality 
ip, we have {Mp, id) \= p Lcnwc F- 

As a consequence of the Characterization Lemma, we also get that for any sub- 
stitution 9 G Substs^ (which is also a valuation over Mp) and any non-strict 
or strict equality p, we have (Mp,9) \= p Lcnwc F^- 
Theorem 3 (Adequateness of Mp). Mp is a model ofV, for any non-striet 
or striet equality p, the following eonditions are equivalent: 

a) V '^cnwc F- 

b) {A,r]) ^ p for every A\=V, and every iq G DefVal{A). 
e) {Mp,\d) ^ p, where id is the identity valuation. 

Note that the completeness of l"C 7 ?,W£ also follows from Theorem 3. According 
to this result, Mp can be regarded as the intended (canonieal) model of pro- 
gram V. In particular, a given f G F will denote a deterministic function iff 
fMv ^ jg ideal for all U G Termp_^ . 

5 On the Power of Magic 

In this section we will present the basic ideas of the bottom-up evaluation method 
for our functional logic language. The main idea in the goal solving of a lazy 
functional logic language under a top-down evaluation, is to select a subgoal 
(strict equation) at a time and to reduce, by applying narrowing steps, every 
side of the equation as far as needed until terms in both sides are found. The 
narrowing steps involve, as it is expressed in CRWL, to select a program rule for 
the outermost function symbol, to solve lazily non-strict equations as parameter 
passing in the function’s calling and to solve the subgoals of the conditions of 
the applied rule. 

Bottom-up evaluation will solve goals obtaining by means of the fix point 
operator a Herbrand algebra in which every strict equality in the goal is satis- 
fied. Like logic programming, the so-called passing magic (boolean) functions will 
activate the evaluation of the functions through the fix point operator, whenever 
there exists a call, passing the arguments from the head to the body and condi- 
tions of every program rule for them. In every step of the fix-point operator appli- 
cation, new approximations to the value (or values, due to the non-determinism) 
of every function are computed. 
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Table 1. Example 1 

(1) f(s(s(A)),B) := B h(A,C) == 0, p(C) == s(0),t(0) == 0. 

(2) g(s(D)) := s(g(D)). 

(3) h(s(E),s(0)) :=0. 

(4) p(s(I)) := s(p(I)). 

(5) p(0) :=0. 

(6) t(0) :=0. 

(7) t(s(0)) :=0. 

(8) k := 0. 

(9) k:=s(0). 

(10) k := s(s(0)). 

Let the program example in table 1^ and the goal f (g(X) ,Y)==t(k) be, 
wherein program rules with conditions, terminating and non-terminating recur- 
sion, non-strictness, and non-determinism are mixed. 

In a top-down evaluation, f (g(X), Y) is narrowed by applying a program rule 
for f like (1) shown in table 1. However, g(X) must be lazily unihed previously 
with s(s(A)), and Y with B respectively. Once unified, the bindings for A and B in- 
stantiate the conditions <1= h(A, C) == 0, p(C) == s(0), t(0) == 0 which became 
subgoals; similarly with t(k). 

In functional- logic bottom-up evaluation the passing magic function for f, 
named mg_f'’, activates the evaluation of the body and the conditions for the 
binding obtained by the lazy unification of g(X) with s(s(A)) and Y with B, 
and therefore obtaining approximations for (instances of) f(g(X),Y) by means 
of the fix-point operator. Similarly with t(k). The approximations computed for 
(instances of) f(g(X),Y) and t(k) are compared in every step of the fix-point 
operator application and the goal solving successes every time that some (due 
to non-determinism) of the approximations agrees, for a particular case of the 
goal, in a total term. 

The magic transformation transforms every pair {V^Q), where "P is a program 
and I? is a goal, into a pair ('pAre^gAiS^ such a way that the transformed pro- 
gram, evaluated by means of the fix point operator, computes the same solutions 
9 of the goal G w.r.t. the program P. 

The transformation process needs the use, in some cases like in our run- 
ning example, of auxiliary intermediate functions whenever there exist nested 
constructors occurring in the head of the rules; for instance, f(s(s(A)),B) 
forces to use an auxiliary intermediate function, called fi, and to add the rules 
f(s(A),B) fi(A, B) and fi(s(C),D) := D replacing (1) shown in the table 1 
which preserves the semantics of f in the original program. 

Once the quoted intermediate functions have been introduced, the magic 
transformation transforms the program, aided by the passing magic boolean 
functions mg_f i’’, mg_g'’, etc., into a filtered program (rules (l)-(ll) shown 

in table 2) where passing magic functions mg-f^{t) == true will filter the fix 
point evaluation for those functions needed by the goal solving. The passing 
magic functions have its own program rules (see rules (12)-(16) shown in table 
2) activating the evaluation of the body and the left-to-right evaluation of the 
conditions. In our example, the passing magic function for f will activate the 
evaluation of f i by rule (1), the magic function for fi will activate the evaluation 

^ We rename program rules in our examples. 
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Table 2. Example 1 



Filtered Rules 

(1) f (s(A) ,B) := fi(A,B) ^ mg_f*’(s(A), B) — — true. 

(2) fi(s(C),D) :=D ^ mg_f5'(s(C),D) true,h(C,E) 0, 

p(E) s(0),t(0) 0. 

(3) g(s(F)) := s(g(F)) mg.g'’(s(F)) == true. 

(4) h(s(G), s(0)) := 0 mg_h*’(s(G), s(0)) == true. 

(5) p(s(H)) := s(p(H)) mg.p'lslH)) = true. 

(6) p(0) := 0 mg_p^(0) true. 

(7) t(0) := 0 mg_t^(0) true. 

(8) t(s(0)) 0 ^ mg_t*’(s(0)) true. 

(9) k := 0 mg_k^ true. 

(10) k := s(0) nig_k^ true. 

(11) k := s(s(0)) mg_k*’ true. 

Magic Rules 

(12) mg_f;(l,J) :^mg_f"(s(l),J). 

(13) mgJi’’(K,L) := mg.ff(s(K),Li). 



: h(N,M) == 0. 

: h(R, T) == 0,p(T) == s(0). 



(14) mg_p’’(M) := mg_f^(s(N) , P) 

(15) mg_t’’(0) := mg_f^(s(R),S) 

(16) mg.p'’(U) := mg.p''(s(U)). 

(17) mg.f;(s(mg^"(V)),Xi) := mg.f;(mg.g"(s(V)),Xi). 

(18) mg.f’’(s(mg^"(Yi)),Z) := mg.f'’(mg.g"(s(Yi)), Z). 

(19) mg_t’’(0) := mg_t'’(mg_k"). 

(20) mg_t’’(s(0)) := mg_t‘’(mg_k"). 

(21) mg_t’’(s(s(0))) := mg_t’’(mg_k"). 

(22) mgJi’’(s(mg_g"(Ai)),Bi) := mgJi’’(mg_g"(s(Ai)) , Bi) . 

(23) mg_f’’(mg_g"(X), Y) := true. 

(24) mg_t^ (mg_k^ ) ;= true. 

Goal Solving Rules 

(25) f(mg_g"(s(Ci)),Di) := f(s(mg_g"(Ci)),Di) mg_f'’(mg_g"(s(Ci)), Di) == true. 

(26) fi(mg_g"(s(Ei)),Fi) := fi(s(mg_g"(Ei)), Fi) mg_f'(mg_g"(s(Ei)), Fi) == true. 

(27) h(mg_g"(s(Gi)),Hi) := h(s(mg_g"(Gi)) , Hi) mgJi'’(mg_g"(s(Gi)), Hi) == true. 

(28) t(ing_k^) ;= t(0) mg_t*’(mg_k”) — — true. 

(29) t(ing_k“) ;= t(s(0)) -4^ mg_t'’ (mg_k” ) — — true. 

(30) t(ing_k“) := t(s(s(0))) ^ mg_t^ (mg_k” ) — — true. 



of h, p and t, as they appear as outermost function symbols of the conditions of 
the rule (2) for f i and finally, the magic function for p will trigger the recursion 
in p by rule (5). In the general case, the transformation process adds only magic 
rules for the outermost function symbols (set denoted by outer{V, G)), which are 
defined as those ones occurring either in the goal, or in the body and conditions 
of some program rule of the outermost function symbols, or in the conditions of 
some program rule of function symbols occurring in the scope of an outermost 
function symbol. 

Secondly, the idea is that whenever a function symbol is in the scope of an 
outermost function symbol, every program rule for the inner function symbol 
generates a rule for the passing magic function of the outermost one. In our 
example g(s(D)) := s(g(D)), and k := 0,k := s(0),k := s(s(0)), generate the 
rules ( 17 )-( 21 ) shown in table 2 for f i, f , and t, respectively. The head and the 
body of every program rule of each inner function symbol are “turned around” 
and introduced as arguments of the head and the body, respectively, of the magic 
rule for the outermost function symbol, occurring at the same position where 
they appear in the goal, and filling the rest of arguments with fresh variables. The 
conditions of the program rules for the inner function symbol, if any, are added 
as conditions of the magic rule for the outermost one. The inner function symbols 
are substituted in the magic rules by the so-called nesting magic constructors, 
given that patterns in program rules must be terms. 
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Moreover, like in our running example, given that g becomes an inner function 
symbol for h due to the information passing from the first argument of fi to h in 
the rule (2), then the rule (22) shown in table 2 is also included. In the general 
case, for every information passing from the head to an outermost function 
symbol in the body and conditions, a magic rule of this kind for the outermost 
symbol is added. 

Furthermore, the facts (23) and (24) shown in table 2 are introduced for the 
given goal, which activate the evaluation of the outermost symbols f and t in the 
goal. Therefore, the evaluation of the outermost function symbols, which appear 
in the bodies and conditions of every program rule for f and t, is activated by 
means of the corresponding magic rules. This is the same class of transformation 
of a program rule in the particular case of a goal. 

Thirdly, the goal f (g(X) ,Y)==t(k) is transformed into a new magic goal 
f (mg_g”(X), Y) == t(mg_k*'). In the general case, given a goal Q, every equation 
e == e' € Q is transformed into a new equation wherein each inner function 
symbol is replaced by nesting magic constructors. 

Finally, the rules (25)- (30) shown in table 2 must be added. These rules, 
also named “goal solving rules” , allow us to solve the new magic goal whenever 
the original one has been modified. In our case, the goal solving rules just are 
the corresponding ones for the magic rules (17)-(22). 

Once the program has been transformed, the operational mechanism of the 
bottom-up evaluation simulates the lazy unification, and the passing of the bind- 
ing obtained by the unification up to the body and conditions of the program 
rules. With respect to lazy unification, and starting with the fact (23), the rules 
(18), (12) and (17) simulate the evaluation of g for unifying with the first ar- 
gument of f . The magic rules (13), (14) and (15) make the information passing 
up to the conditions of fi. The rule (22) allows to evaluate lazily g for unifying 
with the first argument of h. Therefore g is evaluated three times in order to 
apply the rule of f . In general, the magic rules allow to pass the (partial) evalu- 
ation of the inner function to evaluate the outermost one for the given (partial) 
result. 

Let remark us that given that our transformation cannot bring forward 
the required narrowing steps, some magic rules are introduced but not used. 
For instance, let the program f(s(X)) := X h(X) == X, h(s(X)) X and 
g(0) s(s(0)) and the goal f(g(0)) == 0 be, the transformation generates 

mgJi'’(X) := mg_f'’(s(X)), mg_f'’(s(s(0))) := mg_f'’(mg_g’'(0)), mg_h'’(s(s(0))) := 
mgJi'’(mg_g”(0)), but given that g only needs to be evaluated once, the last magic 
rule is never applied, corresponding to lazy evaluation of g. 

Note that the fact that every program rule of the inner functions is intro- 
duced as argument of the magic rule for the outermost function, is justified as a 
mechanism of a demanded driven evaluation of the outermost function symbol; 
that is, the inner symbol is evaluated as far as needed to unify lazily with the 
patterns of every rule of the outermost symbol. The magic transformation passes 
the inner symbols up to the conditions in order to check if the conditions demand 
the evaluation of some of the arguments. For instance, let the program h(Y) := 
0 s(Y) == s(0), g(0) := s(f (0)) and f (0) 0 and the goal h(g(0)) == 0 be. 
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Table 3. Bottom-Up Evaluation 

© -Kmq = -L 

© = '^%Mg © = true,mg.t‘‘(mg_k") = true} 

© = {X/s(Yi),Y/Z} = 'X'-.pMg © {■“g-f'(s(”'g-g"(Yi)),Z) = true, 

mg_t^(0) — true, mg_t^(s(0)) — true, mg_t^(s(s(0))) — true} 

0 O2 = «1 O {I/mg.g"(Yi), J/Z} H^^Mg = 'H'-pMg © {t(s(0)) = O.t(o) = 0, 

'“g-fi(”'g-g”('''i), Z) = true} 

Q 03 = 02 0 {Yi/s(V),Z/Xi} = tt^^g U {mg_£;(s(mg.g"(V)),Xi) = true, t(mg_k") = 0} 

Q 0^ = 03 0 {K/mg.g"(V),Li/Xi} = H'tpMg U {mgji'’ (mg ^ (V) , L) = true} 

0 6*5 = 6I4 o {V/s(Ai),L/Bi}'Hpjg,g = 'H’ipMg U {mgJi'’(s(mg_g"(Ai)),Bi) = true} 

Q 03 = 03 0 {G/mg.g"(Ai), B,/s(0)} H^^g = tt^^g U {h(s(mg^"(Ai)), s(0)) = 0} 

Q 01 = 03 0 {Gi/Ai,Hi/s(0)}-H"^^g = U{h(mg^"(s(Ai)).s(0)) =0} 

Q 03 = 0JO {N/mg.g"(s(Ai)), M/s(0), P/Xi} = 'H^^Mg U {mg.p’’ (s(0) ) = true} 

Q 0g = 03 0 {U/0} n'^Mg = 'H^^^Mg © {”'g-P'’(0) = ^rue} 

© = «“ais © {P(0) = 0} 

© Oio = 02 0 {H/0} H'-^Mg = H'^Mg u {p(s(0)) = s(0)} 

© Oil = eio o {T/s(0),R/mg.g"(s(Ai)),S/Xi} U^^Mg = 'H'^Mg U {mg.t'’(0) = 0} 

© 6i2 = flu o {C/mg^“(s(Ai)),D/X,,E/s(0)} H^^g = H^^g U {f.(s(mg^"(s(A0)), Xi) = Xi} 
© (?13 = O12 o {Ei/mg^"(s(Ai)),Fi/X,} nl^Mg = Hl^^g U {fi(mg^"(s(s(Ai))), X.) = Xj 
© (?14 = fll 3 o {A/mg^"(s(s(A,))),B/Xi} U'^Mg = U'^Mg © (f (s(mg-g"(s(s(Ai))), Xi) = Xj 
© 015 = 014 o {Ci/s(s(Ai)),Di/Xi} H"j^g = H^^Mg U {f(mg^“(s(s(s(A,)))),Xi)) = Xi, 
t(mg_k") = 0} 



then the magic transformation generates mg_h'’(s(mg_f“(0))) ;= mgji'’(mg_g“(0)), 
mgJi^(Y) := mgJi'’(s(Y)), and mg_hi(0) := mgji^(mg_f”(0)). Therefore g(0) is de- 
manded for satisfying the condition s(Y) == s(0). 

In summary, in order to get laziness, there is an imposed condition to pass 
program rules (for inner symbols) as arguments of magic rules for outermost 
symbols: either the corresponding pattern of the outermost function is a con- 
structor term or it is a variable occurring in a safe position (i.e. out of the scope 
of a function symbol) in the body or condition. Both cases ensure the laziness of 
the evaluation process. Otherwise, that is, if the variable occurs in the scope of 
a function symbol / then there could exist the corresponding magic rule for /. 

For instance, let f (g(0)) == 0 the goal and the program f(s(X)) := X, g(0) := 
s(0) be, then there is a passing magic rule mg_f'’(s(0)) := mg_f'’(mg_g”(0)), ex- 
pressing that f demands the evaluation of g for lazily unifying with the pattern 
s(X) . Now, let f (g(0)) == s(0) the goal and the program f(Y) := s(Y), g(0) := 0 
be, then there exists the same passing magic rule mg_f'’(0) := mg_f'’(mg_g“(0)), 
since f is an outermost symbol (thus occurring in the goal or in a subgoal) , and 
for complying with the strict semantics, Y must be necessarily evaluated. How- 
ever, there are no passing rules of this class whenever f (T) := h(T) and h(Y) := 0, 
given that both f and h are non-strict in T and Y, respectively. 

The bottom-up evaluation (shown in table 3) of the magic program in table 2 
with the fix point operator of the definition 8 ends (that is, the Herbrand model 
for the magic program is computed in a finite number of steps) computing 9 = 
{X/s(s(s(Ai))), Y/0} as answer; that is, the instance f (mg_g”(s(s(s(Ai)))), 0) == 
t(mg_k”) is satisfied in the computed Herbrand model. 

The algorithm for the magic transformation is shown in tables 4 and 5, where 

— t\i represents the subterm of t at position i 

— e[e'Ji represents e replacing the subexpression at position i by e' 
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— safe((p) represents the sub-expression of out of the scope of a function 

symbol 

- is dehned as =def X, c(e) ^ =def c(e^) and /(e)^ =de/ an d 

=def X, c(e)'"g" =def c(e™g^) and /(e)™®'" =def 
that is, the inner function symbols are replaced by nesting magic constructors 

- is defined as X^ =def X, c{e)^ =def c(e^) and f{e)^ =def^ mg.f^{e"^s^); 
that is, the outermost function symbols are replaced by passing magic func- 
tions and the inner function symbols by nesting magic constructors. 

— The meaning of the algorithm parameters is as follows: e represents the 
expression or sequence of expressions to be considered (there can be subex- 
pressions occurring in the goal or in some program rule); h(f) is the head of 
a program rule; the boolean Rule? is true whenever the parameter hit) has 
been input; / is a function symbol representing that e is in the scope of the 
outermost symbol /; the boolean Nested? is true whenever the parameter / 
has been input; C represents conditions of some program rule or goal; Mg 
represents the computed set of magic rules; Pg represents the computed set 
of program rules; ind indicates the position of e in the scope of the outermost 
symbol / and G represents a set of triples (/, g, i) where each triple means 
that the function g is nested by / at position i. 

The algorithm transforms every pair {V,Q), where "P is a program and is a goal, 
into a pair such a way that the transformed program, evaluated 

by means of the fix point operator, computes the same solutions 0 of the goal G 
w.r.t. the program P. It is applied as follows: 

C := 0; Mg := 0; Pg := P; G := 0; ind := 0; 
for every e == e' £ Q do 
Magic_Alg(e,_,/aZse,_/a/se, 0, Mg, Pg, ind, G); 

Magic_Alg(e', _,/a/se, _,/aZse, C, Mg, Pg,ind, G); 

C ■=CG{e== e'} 
endfor 

where denotes arguments not needed for the calling. 

Once the algorithm has been applied, P^^ consists of U Mg, where 
if{t) := r <;= C)^ is of the form f{t) := r 5= mg_f^{t) == true,C, and 
consists of CUC^^ and where and denote the set of nesting 

magic constructors, and passing magic functions, respectively. consists of 
the set e^ == e'^ for each e == e' £ Q. 

The basic idea of this algorithm is starting from the goal to traverse the 
program rules of the outermost function symbols in the goal. For every traversed 
program rule the algorithm includes in Mg the magic rules of the information 
passing from the outermost symbols to the body and conditions in its rules; and 
in Pg the new rules for the outermost symbols. 

The parameter G includes the collection of occurrences of inner function 
symbols in outermost function symbols in order to use it in each information 
passing. 

The main algorithm Magic_Alg uses an auxiliary algorithm Nesting which 
introduces the rules of inner function symbols as arguments of the outermost 
ones in both new and magic rules. 
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Table 4. Magic Algorithm 

]V[agic_Alg(in e : tuple(Expression); in h{i) : Expression; in Rule? : Bool; 
in / : FunctionSymbol; in Nested? : Bool; in C : Goal; in/out Mg : Program; 
in/out Pg : Program; in/out ind : Index; in/out G : set{tuple{FunctionSymbol, 
FunctionSymbol, Index))) 
var G" : Goal; 
if Nested? then 

if Rule? then Mg Mg U mg^h^{t) G} 

else Mg := Mg U {find{e)^ := true} 

endif; 

for every ei , . . . , 6n do 
case ei of 
X, X G V : 
if Rule? then 

if {{h,k,j) G G) and {t\j = X) then 
G G U {{find-, k, z)}; Nesting(A:, /, Mg, Pg, ind, i, G); 

endif; 

endif; 

c(e'), c e : 

for every find{t) ■.= r ^ C' G Pg do 
if {ti = c{t') and not {t' = X and X Pi {safe{r) U safe{C')) — 0)) then 
Pg ■.= PgU {f,„d+,{i[t']i) := r ^ C, f,„d{X[c{V)]y := fi„d+,{X[V]i)‘^}-, 
Mg := MgU{find+,{X[V]if := find{X[c{V)]if}-, 

endif ; 

if {ti G V and U G safe{r) U safe{G')) then 

Pg ■.= PgU {fi„d+l{i) -.= r^ C, fi„d{X[c{V)]i)'^ ■■= fi„d+,{X[V]i)‘^}-, 

Mg := MgU{find+,{X[V]if := find{X[c{V)]if}-, 

endif; 

endfor; 

ind ind + 1 ; Magic. Alg(e', h{i). Rule?, f , true, G , Mg, Pg, ind, G ) ; 
k{e'), k G E : 
if {{find,k,i) ^ G) then 

G := G U { {find-, *)} j Nesting(fc, f , Mg, Pg, ind, i, G); 

Magic_Alg(mp_fc^ {e'), h{i). Rule? , f , true, G , Mg , Pg, ind, G) ; 

endif; 

endcase; 

endfor; 

else 

for every ei , . . . , en do 
case ei of 

c{e'), c G C : _ 

Magic_Alg(e^, h{t). Rule?, —, false, C , Mg , Pg , ind, G); 
k{e'), k G E : 

Magic_Alg(e', h{t). Rule? , k, true, G, Mg, Pg, ind, G); 
for every fc(s) r G' G Pg do 
Magic_Alg(r, k{s), true, —, false, C' , Mg, Pg, ind, G); 

C" 0; 

for every e == e' G G' do 

Magic_Alg(e, k{s), true, —, false, G" , Mg , Pg , ind, G ) ; 

Magic_Alg(e^, k{s), true, — , false, C" , Mg, Pg, ind, G); 

C" C"U{e== e'} 

endfor; 

endfor; 

endcase; 

endfor; 

endif; 



In the magic algorithm, we can distinguish the following main cases: (a) 
nested expressions (in the scope of an outermost function symbol) and (b) non- 
nested expressions (out of the scope of an outermost function symbol) : 

(a) in this case, let / the outermost function symbol and e the expression nested 
by / be, then a passing magic rule from the head of the rule to the nesting 
expression is included. In the particular case of the goal, the passing magic 
rule is a fact (see rules (12)-(16) and (23)-(24)). 
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Table 5. Nesting Transformation 

Nesting(in k : FunctionSymbol', in / : FunctionSymbok, in/out Mg : Program; in/out 
Pg : Program;in ind : Index; in i : Index; in G : set{tuple{FunctionSymbol, 
FunctionSymbol, Index))); 
var C" : Goal; 

for every find(i) r C G Pg do 

if {ti ^ V) or ((ti G V) and (U G safe{r) U safe{G))) then 
for every k{s) r G' G Pg do 

M, := M, U {find(X[r']i)^ := f,„d(X [k{s)]y C'}; 

P, := P, U {/„d(X[fc(J)]0" ■=find{X[r']i)‘^ ^ C'}; 

Magic_Alg(r', fc(s), true,f, true, G' , Mg, Pg, ind, G); 

C" 0 ; 

for every e = = e' G C' do 

]Magic_Alg(e, /ind (X [A:(s)]i)^ , true, — , false, G" , Mg , Pg , ind, G ) ; 
Magic_Alg(e^ , find(i^ i true, — , false, C" , Mg , Pg , ind, G); 

G" C" U{e ==_e}; 

Mg := Mg U {find(X[e]if ■.= find{X[k{S)]if , 
find{X[e']if ■.= fi„d(X[k{s)]i)^}- 

endfor; 

endfor; 

endif; 

endfor; 



• If e is a variable occurring in a program rule for h, and it occurs in 
the head, then the algorithm checks using G ii h nests some function in 
the position of the variable in the head; if any, the algorithm passes the 
nested function as argument of / (see rule (22)). 

• If e is a constructor expression, the algorithm introduces the quoted 
auxiliary functions (see rules (l)-(2)). 

• Finally, if e is a functional expression fc(e), the algorithm passes every 
rule of k as argument of the outermost symbol / in each rule of /, 
whenever the nested expression k{e) is demanded by the rule; that is, 
the pattern of the rule is a constructor term or it is a variable occurring 
in a safe position of the body or conditions (see rules (17)-(22) and 
(25)-(30)). 

(b) In the case of non-nested expression, the algorithm has only to decompose 
the arguments, so that if the expression is a functional one (there exists an 
outermost function symbol), then each rule for it must be analyzed. 

6 Soundness, Completeness and Optimality 

In this section we present our soundness, completeness and optimality results of 
our evaluation method based on the magic transformation proposed. From now 
on, we suppose there is a program "P, a goal Q and ^ gMG represents the pro- 
gram and goal obtained by following the magic transformation. Our first result 
establishes the equivalence among both the original and transformed program 
w.r.t. the given goal. 

Theorem 4 (Soundness and Completeness). P hcKWC ^ pXiQ 

g^e. 

The second result ensures optimality of our bottom-up evaluation method, 
in the sense of, every value computed for a function symbol corresponds either 
with a subproof of a proof of some solution for the goal, or with a subproof for 
a non-strict equation involved in the lazy unification of an expression with the 
pattern of a rule of an outermost function symbol. Moreover, the result assures 
that each computed magic fact corresponds with one of the evaluated functions. 
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Theorem 5 (Optimality). 

_ jjpMQ |~c 7 ?,w£ /(e)^ — > t, t ^ _L, then f G outer{V, Q) and either: 

• there exist 9, a proof P \^ctzwc G9 of minimal size and a subproof of the 
form V 'Gcnwc /(e) -> t 

• or there exists f{t) := r <= C G [V] sueh that V 'Gcnwc e^ ^ U is a 
proof of minimal size. 

— jjpMQ Gctzwc fk{S)^ ^ t,tf^ 1- then f G outer{P,G) and either: 

• there exist 0, a proof V \^enwc G9 of minimal size and a subproof of the 
form V \~CRWC /(e') ^ t eontaining subproofs V 'ncKWC Ci ^ U for 
some f{F) := r ^ C G \P] 

• or there exists f{i) := r <= C G [P] sueh that P \^cnwc e^ ^ U is a 
proof of minimal size. 

— ij pM-Q Gcnwc /(e)^ — > true then there exists a proof P^^ 'Gc'r.wc 
f{e)^ — > t for some t. 

7 Conclusions and Future Work 

In this paper, we have presented a framework for goal-directed bottom-up evalu- 
ation of functional logic programs. We have shown that our evaluation method is 
sound and complete w.r.t. a conditional rewriting logic which provides logic foun- 
dations to our functional logic language. We have also proved that our method is 
optimal, that is, the computed “facts” can be mapped with subproofs of a proof 
for some solution of the goal. We want to remark that our magic algorithm also 
provides a transformation for functional logic programs which can be used under 
a top-down evaluation; in fact a Prolog interpreter as: 

X == X : -var(X). 

c(Xi,...,Xn) == c(Yi,... ,Yn) : -Xi == Yi,...,X„ == Y^. % for every cGC 
X == Y : -X := Z, Z == Y. 

X == Y : -Y := Z,X == Z. 

where every rule is dehned as a Prolog rule of the form: f(t) := r : — C., eval- 
uates goals with a top-down lazy narrowing strategy. Similarly, we could write 
a bottom-up interpreter in the line of the presented for logic programming in 
[6]. We expect that other magic transformations presented in the literature can 
be successfully applied in our framework. As future work, we will study how 
to consider, like the most deductive query languages, the dealing with negative 
goals in our language. Moreover, we would like to provide an implementation of 
our framework based on the indexation of the original and magic rules as well 
as the management of the secondary memory. 

Acknowledgements: We would like to thank anonymous referees for their use- 
ful comments. 
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Abstract. The aim of this paper is to provide theoretical foundations 
for the declarative debugging of wrong answers in lazy functional logic 
programming. We rely on a logical framework which formalizes both the 
intended meaning and the execution model of programs in a simple lan- 
guage which combines the expressivity of pure Prolog and a significant 
subset of Haskell. As novelties w.r.t. to previous related approaches, we 
deal with functional values both as arguments and as results of higher 
order functions, we obtain a completely formal specification of the debug- 
ging method, and we extend known soundness and completeness results 
for the debugging of wrong answers in logic programming to a substan- 
tially more difficult context. A prototype implementation of a working 
debugger is planned as future work. 



1 Introduction 

Traditional debugging techniques are not well suited for declarative program- 
ming languages, because of the difficult-to-predict evaluation order. In the field 
of logic programming, Shapiro [19] proposed declarative debugging (also called 
algorithmic debugging) , a semi-automatic technique which allows to detect bugs 
on the basis of the intended meaning of the source program, disregarding op- 
erational concerns. Declarative debugging of logic programs can diagnose both 
wrong and missing computed answers, and it has been proved logically sound 
and complete [2,8]. Later on, declarative debugging has been adapted to other 
programming paradigms, including lazy functional programming [15-17,11,14] 
and combined functional logic programming [13,12]. A common feature of all 
these approaches is the use of a computation tree whose structure reflects the 
functional dependencies of a particular computation, abstracting away the evalu- 
ation order. In [12], Lee Naish has formulated a generic debugging scheme, based 
on computation trees, which covers all the declarative debugging methods cited 
above as particular instances. In the case of logic programming, [12] shows that 
the computation trees have a clear interpretation w.r.t. the declarative semantics 
of programs. On the other hand, the computation trees proposed up to now for 
the declarative debugging of lazy functional programs (or combined functional 
logic programs) do not yet have a clear logical foundation. 
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The aim of this paper is to provide firm theoretical foundations for the declara- 
tive debugging of wrong answers in lazy functional logic programming. Adapting 
a logical framework borrowed from [5,4], we formalize both the declarative and 
the operational semantics of programs in a simple language which combines 
the expressivity of pure Prolog [20] and a significant subset of Haskell [18]. Our 
approach supports a simple syntactical representation of functions as values. Fol- 
lowing the generic scheme from [12], we define a declarative debugging method, 
giving a formal characterization of computation trees as proof trees that relate 
computed answers to the declarative semantics of programs. More precisely, we 
formalize a procedure for building proof trees from successful computations. This 
allows us to prove the logical correctness of the debugger, extending older re- 
sults from the field of logic programming [2, 8] to a substantially more difficult 
context. Our work is intended as a foundation for the implementation of declar- 
ative debuggers for languages such as TOy [10] and Curry [7], whose execution 
mechanism is based on lazy narrowing. 

The paper is organized as follows. Sect. 2 presents the general debugging scheme 
from [12], recalls some of the known approaches to the declarative debugging of 
lazy functional and logic programs, and gives an informal motivation of our own 
proposal. Sect. 3 introduces the simple functional logic language used in the rest 
of the paper. In Sect. 4 the logical framework which gives a formal semantics 
to this language is presented. Sect. 5 specifies the debugging method, as well as 
the formal procedure to build proof trees from successful computations. Sect. 6 
concludes and points to future work. 

2 Debugging with Computation Trees 

The debugging scheme proposed in [12] assumes that any terminated compu- 
tation can be represented as a finite tree, called eomputation tree. The root of 
this tree corresponds to the result of the main computation, and each node 
corresponds to the result of some intermediate subcomputation. Moreover, it is 
assumed that the result at each node is determined by the results of the children 
nodes. Therefore, every node can be seen as the outcome of a single eomputation 
step. The debugger works by traversing a given computation tree, looking for 
erroneous nodes. Different kinds of programming paradigms and/or errors need 
different types of trees, as well as different notions of erroneous. A debugger is 
called sound if all the bugs it reports do really correspond to wrong computa- 
tion steps. Notice, however, that an erroneous node which has some erroneous 
child does not necessarily correspond to a wrong computation step. Following 
the terminology of [12], an erroneous node with no erroneous children is called 
a buggy node. In order to avoid unsoundness, the debugging scheme looks only 
for buggy nodes, asking questions to an oraele (generally the user) in order to 
determine which nodes are erroneous. The following relation between buggy and 
erroneous nodes can be easily proved: 

Proposition 1 A finite eomputation tree has an erroneous node iff it has a 
buggy node. In partieular, a finite eomputation tree whose root node is erroneous 
has some buggy node. 
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This result provides a ‘weak’ notion of completeness for the debugging scheme 
that is satisfactory in practice. Usually, actual debuggers look only for a topmost 
buggy node in a computation tree whose root is erroneous. Multiple bugs can 
be found by reiterated application of the debugger. 

The known declarative debuggers can be understood as concrete instances of 
Naish’s debugging scheme. The instances of the debugging scheme needed for 
diagnosing wrong and missing answers in pure Prolog are described in [12]. In 
these two cases, computation trees can be formally defined so that they relate 
answers computed by SLD resolution to the declarative semantics of programs 
in a precise way. This fact allows to prove logical correctness of the debugger 
[2,8]. The existing declarative debuggers for lazy functional [15-17,11,14] and 
functional logic programs [13, 12] have proposed different, but essentially similar 
notions of computation tree. Each node contains an oriented equation /ai...a„ = 
r corresponding to a function call which has been evaluated, together with the 
returned result, and the children nodes (if any) correspond to those function 
calls whose evaluation became eventually needed in order to obtain /ai...a„ = 
r. Moreover, the result r is displayed in the most evaluated form eventually 
reached during the computation, and the same happens for each argument a,, 
except in the case of the root node ^ . Such a tree structure abstracts away the 
actual order in which function calls occur under the lazy evaluation strategy. 
A node is considered erroneous iff its oriented equation is false in the intended 
interpretation of the program, and the bug indication extracted from a buggy 
node is the instance of the oriented equation in the program applied at the 
outermost level to evaluate the function call in that node. 

To illustrate these ideas, let us consider the small program shown in Fig. 1, 
written in Haskell-like, hopefully self-explanatory syntax. The data constructors 
s and 2 : represent the successor of a natural number and the natural number 
zero, respectively, while : acts as an infix binary constructor for non-empty lists 
and [] is a nullary constructor for the empty list. Different defining equations 
for the same function / are labeled as f.i, with indices i > 1. 



(from.l) from N 




- 


-t N : 


: from N j 


(take . D take z 




Xs 


-t [ ] 


(tcike.2) take (s 


N) 


[ ] 


-t [ ] 


(take. 3) take (s 


N) 


(X : Xs) - 


-t X : 


: take W Xs 



Figure 1: A program example 



A function call {take NXs) is intended to compute the first N elements of the 
list Xs, while {from N) is intended to compute the infinite list of all numbers 
greater or equal than N. The definition of from is mistaken, because its right- 
hand side should be {N : from {sN)). Due to this bug, the program can compute 
take {s{s z)) {from 2 ) = 2 : 2 : [], which is false in the intended interpretation. A 
computation tree (built according to the method suggested in [16, 13] and related 

^ In order to avoid this exception, some actual debuggers assume a call to a nullary 
function main at the root node. 
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papers) would look as shown in Fig. 2, where erroneous nodes are displayed in 
boldface and the leftmost-topmost buggy node is surrounded by a double box. 




Figure 2: Computation tree with oriented equations 



To the best of our knowledge, no formal proofs of correctness exist for the known 
lazy functional (logic) declarative debuggers, in contrast to the pleasant results 
shown in [2,8] for the logic programming case. To achieve such a proof, one 
needs a sufficiently formal characterization of the relationship between compu- 
tation trees and a suitable formalization of program semantics. The best at- 
tempt we know to formalize computation trees for lazy functional programming 
has been made in [16], using denotational semantics. However, as the authors 
acknowledge, their definition only gives an informal characterization of the func- 
tion calls whose evaluation becomes eventually demanded^. A more practical 
problem with existing debuggers for lazy functional (logic) languages is related 
to the presentation of the questions asked to the oracle. In principle, such ques- 
tions should ask whether the oriented equations /ai...a„ = r found at the tree’s 
nodes are valid according to the intended program meaning. In these equations, 
both the argument expressions a, and the result expression r can include ar- 
bitrarily complex, suspended function calls. Several solutions to this problem 
have been proposed, trying to ban the offending closures in various ways. In 
particular, Lee Naish [11] suggests the following simplification procedure: to 
replace unevaluated closures within the a, by fresh variables X] to replace un- 
evaluated closures within r by fresh variables Y ; and to append a quantifier 
prefix \fX 3Y in front of the new oriented equation. Applying this simplification 
method to Fig. 2, we obtain that the second child of the root node simplifies 
to yXs. take {s{s z)){z : z : Xs) = z : z : [], while the buggy node simplifies 
to 3Ys. fromz = z : Ys. Note that the simplified question at the older buggy 
node has become valid in the intended program meaning. Therefore, the older 
buggy node is not buggy any more in the simplified tree. Its parent becomes 
buggy instead (and it points to the same program bug). 

The example shows that Naish’s simplification does not preserve the semantics of 
oracle questions. Moreover, a simplified oracle question like X3Y = r' 
has the same meaning as t, where the quantifier prefix has been 

removed and resp. t are obtained from a' resp. r' by substituting the bot- 
tom symbol T (meaning an undefined value) in place of the new variables X, 

^ Maybe this problem has been better solved in [17], a reference we obtained from the 
referees upon finishing the paper. 
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Y introduced by simplification. Due to the occurrences of _L in places where 

suspended function calls occurred before, the meaning of cannot be un- 
derstood as oriented equality any more. Instead, t means that t 

approximates the value of where each approximates the value of 

the original argument expression a,. Coming back to our example, the sim- 
plified question \fXs. take {s{s z)) {z : z : Xs) = 2 : : 2 : : [] is equivalent to 
take (s(sz))(z : 2 : _L) 2 : 2 : [], while BYs.from z = 2 : Ys is equivalent to 

from 2 2 : _L. 

We aim at a debugging method based on computation trees whose nodes include 
statements of the form ft\...tn t, where and t include no function calls, 
but can include occurrences of the undefined symbol _L. Such statements will 
be called basic facts in the sequel. As we have seen, basic facts have a natural 
(not equational) meaning, and they help to obtain more simple oracle questions. 
Moreover, there is a well developed logical framework for functional logic pro- 
gramming [5,4], based on the idea of viewing basic facts as the analogon of 
atomic formulas in logic programming. Relying on a variant of this framework, 
we will obtain a formal characterization of our debugging method. 

3 A Simple Functional Logic Programming Language 

The functional logic programming (FTP for short) paradigm [6] tries to bridge 
the gap between the two main streams in declarative programming: functional 
programming (FP) and logic programming (LP). For the purposes of this pa- 
per, we have chosen to work with a simple variant of a known logical framework 
for FTP [5,4], which enjoys well-defined proof-theoretic and model-theoretic se- 
mantics and has been implemented in the TOy system [10]. In this section we 
present the syntax and informal semantics used for programs and goals in the 
rest of the paper. Pure Prolog [20] programs and Haskell-like programs [18] can 
be expressed in our language. 

3.1 Preliminaries 

A signature with constructors is a countable set E = DCs U FSs, where 
DCs = [JneN DC^ and FSs = U„eN FS^ are disjoint sets of data constructors 
and defined function symbols respectively, each one with an associated arity. In 
the sequel the explicit mention of S is omitted. We also assume a countable set 

V of variables, disjoint from S. 

The set of partial expressions built up with aid of S and V will be denoted as 
Exps and defined as: Exp± ::=T \ X \ h j(ee') with W € V, h G E, e, e' € 
Exp±. Expressions of the form (ee') stand for the application of e (acting as a 
function) to e' (acting as an argument). As usual, we assume that application 
associates to the left and thus (eo ei . . . e„) abbreviates ((. . . (eo ei) . . .) e„). As 
explained in Sect. 2, the symbol T (read bottom) represents an undefined value. 
We distinguish an important kind of partial expressions called partial patterns, 
denoted as Pats and defined as: Pats ::= T j W j ct\ . . . tm\ fti ■ ■ ■ tm where 
ti e Pats, c e DC", 0 < m < n and / € F5", 0 < to < n. Partial patterns 
represent approximations of the values of expressions. Moreover, partial patterns 
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of the form / ti . . .tm with / € FS" and m < n serve as a convenient repre- 
sentation of functions as values; see [4]. Expressions and patterns without any 
occurrence of _L are called total. We write Exp and Pat for the sets of total 
expressions and patterns, respectively. 

Total substitutions are mappings 6 : V ^ Pat with a unique extension 9 : 
Exp Exp, which will be noted also as 0. The set of all substitutions is denoted 
as Suhst. The set Subst± of all the partial substitutions 6 : V ^ Pat± is defined 
analogously. We write e9 for the result of applying the substitution 9 to the 
expression e. As usual, 9 = {Xi/t\, . . . , stands for the substitution that 

satisfies Xi9 = ti, with \ <i <n and = T for all T € V\{Wi, . . . , X„}. 

3.2 Programs and Goals 

In our framework programs are considered as ordered sets of defining rules for 
function symbols. Rule order is not important for the logical meaning of a pro- 
gram. Each rule has a left-hand side, a right-hand side and an optional eondition. 
The general shape of a defining rule for / € F5" is: 

(R) f h .. ,t„ <= ei pi,.. .,6k Pk where: 

left-hand side right-hand side condition 

(i)t\, . . . , tn, Pi, ■ ■ ■ , Pk, (n. A: > 0) is a linear sequence of patterns, where linear 
means that no variable occurs more than once in the sequence. 

(a) r, e\, ..., Ck are expressions. They can contain extra variables that don’t 
appear in the left-hand side. 

(Hi) A variable in p, can occur in Cj only if j > i (in other words: p, has no 
variables in common with ei, . . . , e,). 

Conditions (i), (ii) and (Hi) above are not too restrictive for programming and 
technically helpful to obtain well-behaved goal-solving calculi (as the one pre- 
sented in Subsection 4.3 below). Conditions fulfilling property (Hi) and such 
that the sequence pi , . . . , p^,, is linear will called admissible in the sequel. The 
intended meaning of a rule like (R) is that a call to function / can be reduced 
to r whenever the actual parameters match the patterns ti and the conditions 
6j pj are satisfied. In [5,4], conditions of this kind are called approximation 
statements. They are satisfied whenever Cj can be evaluated to match the pattern 
Pj. The basic facts f t\ . . .t„ ^ t mentioned in Sect. 2 are particularly simple 
approximation statements. Readers familiar with [5,4] will note that joinability 
eonditions e ix e' (written as e == e' in T Oy’s concrete syntax) are replaced by 
approximation eonditions e ^ p in this paper. This is done in order to simplify 
the presentation, while keeping expressivity enough for our present purposes. 
Eig.l in Sect. 2 shows a program for the signature DC = {2:/0, s/1, []/0, : /2}, 
FS = {from/1, take/2}. It will be used as a running example in the rest of this 
paper. The reader is referred to [5,4] for more programming examples. 

A goal in our setting is any admissible condition ei p\, ... ,eu Pk- Goals 
with k = 1 are called atomie. As we will see more formally in the next section, 
solutions to a goal e ^ p are substitutions 9 such that p9 approximates the value 
of e9, according to the semantics of the current program. As in LP, a goal can 
include logie variables that are bound to patterns when the goal is solved. 
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For instance, considering the goal take N {from X)) Yg for our running 
example program, and the goal solving calculus presented in Subsection 4.3, 
the following solutions would be computed in this order: 9i = {N/z, 

02 = {N/{s z), Yg/X : []}; and 0s = {N/s (s z), Yg/X : X : []}. Solution 83 is 
incorrect w.r.t. the intended meaning of the program, which calls for debugging. 
Note that the values for N and X leading to a wrong result can be found by 
the execution system. In a purely FP setting, the user would have been forced 
to guess them. 



4 A Logical Framework for FLP 

We are now ready to formalize a semantics and a goal solving calculus for the 
simple FLP language described in the previous section. We will follow the ap- 
proach from [5,4], with some modifications needed for our present purposes. 



4.1 A Semantic Calculus 



The Semantic Calculus SC displayed below specifies the meaning of our lazy 
FLP programs. SC is intended to derive an approximation statement e ^ t 
from a given program P just in the case that t approximates the value of e, as 
computed by the defining rules in P. In the SC inference rules, e, e, € Exp±_ are 
partial expressions, ti,t,s G Pat± are partial patterns and h G E. Moreover, 
the notation [P]j_ in rule RA stands for the set {(/ ^- r <^= C)0\{1 r <= C) G 
P,9 £ Subst±} of partial instances of the defining rules in P. The SC rules are: 



BT Bottom: e ^-T 
DC Decomposition: 



AR Argument Reduction: 
RA Rule Application: 



RR Restricted Reflexivity: X ^ X, X £ V ar 
6l ^ t\ ... 0172 ^ h £ Pat±_ 



k Cm t h 

^ t\ ... e„ tr 



fir. 



C 



r ^ s 



f tn 



f GnJ^k t, 

5 f in ^ r <= C £ [f’jj. 



S at ^t , f£PS^ 

t^Y 



SC is similar to the rewriting calculus GORC from [5,4]. The main difference is 
that the GORC rule OR for Outer Reduction has been replaced by AR and RA. 
Taken together, these two rules say that a call to a function / is evaluated by 
computing approximated values for the arguments, and then applying a defining 
rule for /. This is related to the strictification idea in [15, 17], which was intended 
as an emulation of the innermost evaluation order, but evaluating the arguments 
only as much as demanded by the rest of the computation. 

The conclusion /t„ s of RA is a basic fact that must coincide with the cor- 
responding premise of AR when the two rules are combined. The older calculus 
GORC did not explicitly introduce such a basic fact, which is needed for debug- 
ging, as we have motivated in Sect. 2. The case A: > 0 in rule AR corresponds to a 
higher order function /, returning as result another function (represented by the 
pattern s) which must be applied to some arguments Ok- Just for convenience, 
we add to the SC calculus the following variant AR' of AR, to be used only in 
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the case A: = 0. It can be shown that SC with AR' is equivalent to SC without 
AR'. 



AR’ 



e\ ^ t\ ... 6n ^ tn 
f en 








(DC) 



Figure 3: Proof Tree in the semantic calculus SC 



We write P h e t to indicate that e ^ t can be deduced from P using SC. 
We also define a correct solution for a goal G = e ^ t w.r.t. program P as any 
total substitution 9 G Subst such that P \- e6 ^ tO. An SC derivation proving 
that this is the case can be represented as a tree, which we will call a proof tree 
(PT) for G9. Each node in a PT corresponds to an approximation statement 
that follows from its children by means of some SC inference. For instance, the 
PT from Fig. 3 shows that 9 = {N/s {s z), Ys/W :W :[]} is a solution for the goal 
take N {from X) Ys w.r.t. our running example program. This is indeed a 
bug symptom. The right solution, according to the program’s intended meaning, 
should he 9 = {N/s {sz), Ys/X:sX : []}. 

4.2 Models 

In LP the intended meaning of a program can be formalized as an intended model, 
represented as a set of atomic formulas belonging to the program’s Herbrand base 
[2,8]. The open Pterbrand universe (i.e. the set of terms with variables) gives raise 
to a more informative semantics [3]. In our FTP setting, a natural analogon to 
the open Herbrand universe is the set Pat± of all the partial patterns, equipped 
with the approximation ordering: t Q t' t' A t ^ \~sc t' ^ t- 

Similarly, a natural analogon to the open Herbrand base is the collection of all 
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the basic facts f tn ^ t. Therefore, we define a Herhrand interpretation as a 
set I of basic facts fulfilling the following three natural requirements, for all 
/ e F5" and arbitrary partial patterns 

• / f n jT-T e T. 

• ii f t„ ^ t & I, ti Q t[,t ^ t' then ft'^^t' £l. 

• ii f t„ ^ t &I, 6 & Subst then (/ t„ t)6 € I. 

This definition of Herbrand interpretation is simpler than the one in [5,4], where 
a more general notion of interpretation (under the name algebra) is presented. 
The trade-off for this simpler presentation is to exclude non-Herbrand interpre- 
tations from our consideration. In our debugging scheme we will assume that the 
intended model of a program is a Herbrand interpretation 2. Herbrand interpre- 
tations can be ordered by set inclusion. In our running example, the intended 
interpretation contains basic facts such as from X ^-T, from X ^ X :±, 
from X ^ X :s X :± or take (s(s 2 :))(X|! : s X|! :T) X -.sX : []. 

By definition, we say that an approximation statement e ^ t is valid in 2 iff 
e ^ t can be proved in the calculus SCi consisting of the SC rules BT, RR and 
DC together with the rule FAi below, whose role is similar to the combination 
of the two SC rules AR and RA-. 

FAx e\ ^ t\ . . . On ^ tn s cik t t pattern, t s pattern 

f 6n Ok ^t f tn ^ s G 2 

For instance, the approximation statement take{s{sz)) (fromX) X :sX :[] 
is valid in the intended model of our running example program. For any basic 
fact ftn^t and any Herbrand interpretation T, it can be shown that ftn^t 
is valid in T iff / 1 € T. The denotation of e € Exp± in 2 is defined as the 

set: |ep = {t & Pat± \ e ^ t valid in 2}. Given a program P without bugs, the 
intended model 2 should be a model of P. This relies on the following definition 
of model, which generalizes the corresponding notion from logic programming: 

• X is a model for P (X |= P) iff X is a model for every program rule in P. 

• X is a model for a program rule I ^ r <^= G ( X |= / r <^= G) iff for any 
substitution 6 € Subst ±, 2 satisfies W ^ rO <^= C6. 

• X satisfies a rule instance I' ^ r' <= C iff either X does not satisfy G' or 
[I'f D |r'f . 

• X satisfies an admissible condition G' iff for any e' ^ p' £ C , |e'p D \p'\^ ■ 

It can be shown that \e'f- D iff p' G [e'p. 

A straightforward consequence of the previous definitions is that X |/= P iff there 
exists a program rule I ^ r <= C, 9 £ Subst± and t £ Pat± such that e9 p9 
is valid in X for any e ^ p £ C , r9 ^ t is valid in X, but 19 ^ t ^ X. Under 
these conditions we say that the program rule I ^ r <^= G is ineorreet w.r.t. 
the intended model X and that (I ^ r <= C)9 is an ineorreet instanee of the 
program rule. In our running example, the program rule fromX X : from X 
is incorrect w.r.t. the intended model X, because X : from X ^ X ■. X -.2 is 
valid in X but from X ^ X ■. X -.2 ^ 2. By & straightforward adaptation of 
results given in [5,4], we can obtain the following relationships between programs 
and models: 
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Proposition 2 Let P be a program and e ^ t an approximation statement. 
Then: 

(a) If P h e ^ t then e ^ t is valid in any Herhrand model of P. 

(h) Mp = {f tn ^ t\P ^ f tn ^ t} is the least Herbrand model of P w.r.t. the 
inelusion ordering. 

(e) If e ^ t is valid in Mp then P h e^t. 

According to these results, the least Herbrand model of a correct program should 
be a subset of the intended model. This is not the case for our running example, 
where the approximation statement take {s{s z)) {from X) X-.X-.[] is valid 
in Mp but not in the intended model. 

4.3 A Goal Solving Calcnlns 

We next present a Goal Solving Caleulus GSC which formalizes the computation 
of solutions for a given goal. GSC is inspired by the lazy narrowing calculi 
from [5,4], adapted to the modified language in this paper. Since we have no 
joinability statements here, the rules to deal with them have been omitted. The 
rules given in [4] to deal with higher order logie variables have been also omitted 
for simplicity; they could be added without any difficulty. 

The GSC calculus consists of rules intended to transform a goal step by step. 
Each step transforms a goal G,_i into a new goal G,, yielding a substitution 
(Tj. This is done by selecting an atomic subgoal of G,_i and replacing it by new 
subgoals according to some GSC rule. Therefore, G5G-rules have the shape 
G, e ^t, G' \\-fj. {G,G” ,G')(Ji. A GSC computation succeeds when the empty 
goal (represented as □) is reached. The composition a of all the substitutions cr, 
along a successful computation is called a GSC eomputed answer for the initial 
goal. 

As auxiliary notions, we need to introduce user-demanded variables and de- 
manded variables. Informally, we say that a variable X is user-demanded if X 
occurs in t for some atomic subgoal e 1 of the initial goal, or X is introduced 
by some substitution which binds another user-demanded variable. Formally, let 
Go = ei ti, ... Ck tk he the initial goal, G,_i any intermediate goal, 
and Gi-i \\-fj. Gi any calculus step. Then the sets of user-demanded variables 
(udvar) are defined in the following way: 
k 

udvar{Go) = U var(ti) udvar{Gi) = [J var{x<Ji), i > 0 

«=1 udvar {Gi-\) 

Let e t be an atomic subgoal of a goal G. By definition, a variable A in t is 
demanded if it is either a user-demanded variable or else there is some atomic 
subgoal in G of the shape: Xeu t, k >0, where t must be also demanded if 
it is a variable. Now we can present the goal solving rules. Note that the symbol 
Ih is used in those rules which compute no substitution. 

DC Decomposition: G, hem ^ him, G’ Ih G, ei — )• ti, . . . t tm, G’ . 

OB Output Binding: G, X ^ t, G' \\~{x/t} {G, G'){X/t\, with t not a variable. 

IB Input binding: G, t ^ X, G’ \\~{x/t} {G, G'){X/t}, with t a pattern and either X 
is a demanded variable or X occurs in (G, G'). 
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IIM Input Imitation: 

G, h 6m — t X, G' Ih {x/ft Tm} ■ ■ ■ ’ Xm, G'){X/hXm} with 

h era not a pattern, Xm fresh variables, h Xm a pattern, and either X is a de- 
manded variable or X occurs in (G, G'). 

EL Elimination: G, e — )• X, G' ll“{x/±} G, G' 

if X is not demanded and it does not appear in (G, G'). 

FA Function Application: G, / Fn a* — >t, G' IF G, ei — >ti, • • • ,en —tin, G, r — 15, 

5 a* — 1 1, G' where 5 must be a new variable, / tn —t r G is a variant of a 
program rule, and t must be demanded if it is a variable. 

The GSC rules are intended to be related to the SC rules in a way which 
will become clear in Subsection 5.1. In particular, the GSC rule FA has been 
modified w.r.t. the analogous rule in the goal solving calculi from [5,4], so that 
it can be related to the combined application of the two SC rules AR and RA. 
As we did in SC, we introduce an optimized variant FA' of rule FA, for the 
case A: = 0: 

FA’ G, f e„ t, G' \\- G, ei ^ ti, . . . , e„ ^ t„, C, r ^ t, C 

where f tn ^ r <= C is a variant of a program rule and t demanded if it is a 

variable. 

As another difference w.r.t. [5,4], where no particular selection strategy was con- 
sidered, here we view goals as ordered sequences of atomic subgoals, and we adopt 
a quasi-leftmost selection strategy. This means to select the leftmost atomic sub- 
goal e t for which some GSC rule can be applied. Note that this is not 
necessarily the leftmost subgoal. Subgoals e ^ X, where X is a non-demanded 
variable, may be not eligible at some steps. Instead, they are delayed until X 
becomes demanded or disappears from the rest of the goal. This formalizes the 
behaviour of shared suspensions in lazy evaluation. In particular, rule EL takes 
care of detecting undemanded suspensions, whose formal characterization was 
missing in previous approaches such as [16]. Below we show the first steps of a 
GSC computation for the goal take N {from X) Ys w.r.t. our running ex- 
ample program. Selected subgoals appear underlined and demanded variables X 
are marked as X!. The composition of all the substitutions yields the computed 
answer: a = {N/s (sz), X^/X :X : []} (wrong in the intended model, as we have 
seen already). 

take N (from X) ^ Ys! IF(fa') N ^ s N’. from X X’:Xs’, X’:take N’ Xs’ Ys! 
II-(OB), {N/sN'} from X ^ X’:Xs’ . X’:take N’ Xs’ Ys! IF(fa') 

X ^ M . M:from M X’:Xs’, X’:take N’ Xs’ Ys! \\-(ib){m/x} • • • □ 

Answers computed by GSC are correct solutions in the sense defined in Sub- 
section 4.1. This soundness result is a straightforward corollary of Proposition 
3, shown in the next section. Regarding completeness, we conjecture that GSC 
can compute all the answers expected by SC, under the assumption that no 
application of a free logic variable as a function occurs in the program or in the 
initial goal. We have not checked this conjecture, which is not important for our 
present purposes. Completeness results for closely related (but more complex) 
goal solving calculi are given in [5,4]. 
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5 Debugging Lazy Narrowing Computations 

In this section we introduce an instance of Naish’s general scheme [12] for debug- 
ging wrong answers in our FLP language. Our computation trees will be called 
the abbreviated proof tree {APTs in short). An APT is obtained in two phases: 
first a SC proof tree PT is built from a successful CSC computation. Then the 
PT is simplified obtaining the APT tree. We next explain these two phases and 
establish the correctness of the resulting debugger. 

5.1 Obtaining Proof Trees from Snccessfnl Compntations 

Given any CSC successful computation Go \\-ai G\ 11-^2 ...G„_i \\-a„ □ with 
computed answer cr = (Ti . . . (t„ , we build a sequence of trees Tq , Ti , . . . , T„ , T as 
follows: 

• The only node in Tq is Gq. 

• For any computation step corresponding to a rule of the CSC different from 
FA and FA': 

G, e ^t, G' Ih^. {G,G" ,G')(Ji the tree T, is built from Ti-iUi by including as 
' . ' ' » ' 

Gi-i Gi 

children of the leaf (e t)oi in Ti-iUi all the atomic goals in G"<Tj. 

• For any computation step corresponding to rule FA of the GSC: 

G , f €n eik t, G' \\- G , e\ ^ t\, . . . ,€n ^ tn, C, r ^ S, S ^ t, G' 
the tree T, is built by ’expanding’ the leaf / enCik t of T,_i as shown in the 
diagram below. Analogously for the case of the simplification of FA, i.e. rule 
FA' , a similar diagram can be depicted. 




(FA) (FA’) 

• Finally, the last tree T is obtained from T„ by repeatedly applying the SC 
rule DC to its leaves, until no further application of this rule is possible. 

For instance, the PT of Fig. 3 can be obtained from the GSC computation 
whose first steps have been shown in Subsection 4.3. The next result guarantees 
that the tree T constructed mechanically in this way is indeed a PT showing 
that the computed answer is a correct solution. 

Proposition 3 The tree T deseribed above is a PT for goal Go<t. 

Proof Sketeh. By induction on the number of goal solving steps, showing that 
the algorithm associates a valid SC step to each GSC rule. This correspondence 
is: 



GSC rule 


DC OB IB IIM EL FA FA’ 


SC rule 


DC - - DC BT AR+RA AR’+RA 



Rules IB and OB only apply a substitution and therefore do not correspond to 
an SC inference step. Therefore, the internal nodes of each tree T, obtained by 
the algorithm correspond to valid SC inferences. Moreover, it can be shown that 
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the leaves of each T, either can be proved by repeatedly applying the SC rules 
DC, BT and RR or occur in G,. This means that once the empty goal is reached 
the tree T„ can be completed as indicated to build the final PT. Note that each 
boxed node in the final PT corresponds to an application of the SC rule RA with 
an associated program rule instance, which comes from some original program 
rule variant, affected by the computed answer a. 

5.2 Simplifying Proof Trees 

The second phase obtains the APT from the PT by removing all the nodes 
which do not include non-trivial boxed facts, excepting the root. More precisely, 
let T be the PT for a given goal G. The APT T' of G can be defined recursively 
as follows: 

• The root of T' is the root of T. 

• Given any node N in T' the children of N in T' are the closest descendants of 
N mT that are boxed basic facts f tn ^ t with t 

• Attached to any boxed fact in the APT, an implicit reference to an associated 
program rule instance is kept. This information is available in the PT. 

The idea behind this simplification is that all the removed nodes correspond 
either to unevaluated function calls (i.e. undemanded suspensions) or to correct 
computation steps, as they do not rely on the application of any program rule. 
To complete an instance of Naish’s debugging scheme [12], we still have to de- 
fine a criterion to determine erroneous nodes, and a method to extract a bug 
indication from an erroneous node. These definitions are the following: 

• Given an APT, we consider as erroneous those nodes which contain an approx- 
imation statement not valid in the intended model. Note that, with the possible 
exception of the root node, all the nodes in an APT include basic facts. This 
simplifies the questions asked to the oracle (usually the user). 

• For any buggy node N in the APT, the debugger will show its associated 
instance of program rule as incorrect. 




Figure 5: APT corresponding to the PT of Fig. 3 

Fig. 5 shows the APT corresponding to the PT of Fig. 3. Erroneous nodes 
are displayed in bold letters, and the only buggy node appears surrounded by 
a double box. The relation between this tree and the computation trees used 
in previous approaches [15-17,11,14,13] has been already discussed in Sect. 2. 
Assuming a debugger that traverses the tree in preorder looking for a topmost 
buggy node (see [12] for a discussion about different search strategies when 
looking for buggy nodes in computation trees), a debugging session could be: 
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from X X:X:_L? no 
from X — >■ X:_L? yes 

Rule ’from.l’ has the incorrect instance ’from X — )• X:from X’ 

5.3 Soundness and Completeness of the debugger 

Now we are in a position to prove the logical correctness of our debugger: 

Theorem 

(a) Soundness. For every buggy node deteeted by the debugger, the assoeiated 
program rule is ineorreet w.r.t. the intended model. 

(b) Completeness. For every eomputed answer whieh is wrong in the intended 
model, the debugger finds some buggy node. 

Proof Sketch 

(a) Due to the construction of the APT, every buggy node corresponds to the 
application of some instance of a program rule R. The node (corresponding to 
R’s left hand side) is erroneous, while its children (corresponding to R’s right 
hand side and conditions) are not. Using these facts and the relation between 
APTs and PTs, it can be shown that R is incorrect w.r.t. the intended model. 

(b) Assuming a wrong computed answer, the root of the APT is not valid in the 
intended model, and a buggy node must exist because of Proposition 1. 

6 Conclusions and Future Work 

We have proposed theoretical foundations for the declarative debugging of wrong 
answers in a simple but sufficiently expressive lazy functional logic language. 
As in other known debuggers for lazy functional [15-17,11,14] and functional 
logic languages [13, 12], we rely on the generic debugging scheme from [12]. As 
a novelty, we have obtained a formal characterization of computation trees as 
abbreviated proof trees that relate computed answers to the declarative seman- 
tics of programs. Our characterization relies on a formal specification of both 
the declarative and the operational semantics, using approximation statements 
rather than equations. Thanks to this framework, we have obtained a proof of 
logical correctness for the debugger, extending older results from the logic pro- 
gramming field to a more complex context. To our best knowledge, no previous 
work in the lazy functional (logic) field has provided a formalization of compu- 
tation trees precise enough to prove correctness of the debugger. As additional 
advantages, our framework helps to simplify oracle questions and supports a 
convenient representation of functions as values. 

As future work we plan an extension of our current proposal, supporting the 
declarative debugging of both wrong and missing answers. This will require two 
different kinds of computation trees, as well as suitable extensions of our logical 
framework to deal with negative information. We also plan to implement the 
resulting debugging tools within the TOy system [10], which uses a demand 
driven narrowing strategy [9, 1] for goal solving. To formalize the generation of 
computation trees for TOy, we plan to modify the goal solving calculus, so 
that the demand driven strategy and other language features are taken into 
account. To implement the generation of computation trees, we plan to follow a 
transformational approach, adapting techniques described in [16, 14]. 
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Abstract. Constraint logic programming languages are an extension of 
logic programming languages where unification has been replaced by con- 
straint solving. Constraint solving techniques allow to reduce the search 
space of a logic program dramatically and have been shown to be useful 
in a wide area of application domains. 

Functional- logic languages are a different branch in the group of declar- 
ative languages, which combine the reduction of expressions with unifi- 
cation. In contrast to purely functional languages, functional-logic lan- 
guages allow for computations with partially known data and offer built- 
in search strategies, allowing for a more concise formulation of programs. 
Compared to purely logic languages, functional-logic languages provide 
functions and a declarative approach to I/O, thus avoiding the need for 
non-declarative language constructs (e.g. the ubiquitous cut in Prolog). 
In this paper we will consider the integration of constraint programming 
and functional-logic programming in the context of the language Curry. 
Curry is a multi-paradigm declarative language, which aims at unifying 
the different lines of research in functional-logic programming. In partic- 
ular, we have chosen the domain of linear constraints over real numbers 
and will describe the semantic and operational issues of this integration. 



1 Introduction 

Curry [HanOO] is a multi-paradigm language that integrates features from func- 
tional languages, logic languages, and concurrent programming. The operational 
model of Curry is based on an optimal reduction strategy [AEH97] which inte- 
grates needed narrowing and residuation. Narrowing [Red85] combines unifi- 
cation and reduction, allowing the non-deterministic instantiation of unbound 
logic variables. The residuation strategy [ALN87], on the other hand, delays 
the evaluation of expressions containing unbound logic variables until these are 
sufficiently instantiated by other parts of the program. 

Constraint logic programming languages replace unification by the concept 
of constraint resolution. In a constraint logic calculus, only clauses whose con- 
straints are consistent will be selected in a resolution step. In general, less clauses 
than in a purely logic program will be selected, reducing the amount of search 
in the program. This results in a more efficient execntion of constraint logic 
programs compared to pnrely logic programs. 
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Constraint solving techniques have proven useful in various domains, includ- 
ing equality constraints for infinite terms, boolean constraints, and linear con- 
straints over finite domains, rational numbers and real numbers. 

While a lot of research has been devoted to the combination of constraint 
programming and logic programming in the CLP paradigm, there have been few 
efforts to integrate constraint programming into functional-logic languages. In 
this paper we will explore the integration of linear constraints over real numbers 
into Curry. We have chosen this domain because there is a wide variation of 
application domains, e.g. financial applications, numerical simulations, or task 
scheduling. In addition there are well known, efficient algorithms for solving 
equalities and inequalities between linear expressions, namely Gaussian elimina- 
tion and the simplex algorithm. One distinguishing feature of our work is the 
integration of optimization constraints into the language. 

This paper is organized as follows. The next section briefly summarizes the 
computation model of Curry. The third section introduces linear constraints over 
real numbers. Section 4 outlines the integration of linear constraints in Curry. 
The fifth section presents the semantics of optimization constraints in Curry. 
The following section sketches how these constraint solving capabilities can be 
integrated into our abstract machine for Curry [Lux99] . The final sections present 
related work and conclude. 

2 The computation model of Curry 

Curry uses a syntax similar to Haskell [HPW92], but with a few additions. 

The basic computational domain of Curry is a set of data terms. A data 
term t is either a variable or an application of an n-ary data constructor to n 
argument terms. 

t :■.= x\ cti ■ ■ ■ tn 

The set vars{t) of variables occurring in a term t is defined inductively. 

vars{x) = {a;} 

U n 

vars{ti) 

i—1 

A data term t is ground if vars{t) = 0. 

New data constructors can be introduced through data type declarations. 
E.g., the type Nat of natural numbers can be defined by 

data Nat = Zero I Succ Nat 

The nullary data constructor Zero represents the natural number 0 and the 
unary data constructor Succ applied to some other natural number denotes the 
successor of that number. 

An expression e is either a variable x, a data constructor c, a (defined) func- 
tion /, or an application of an expression e\ to an argument expression C 2 - New 
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logic variables can be introduced in a let expression. The variables Xi,. . . ,Xn 
are existentially quantified in the body expression e. 

e ::= x I c I / I Cl 62 I let Xi,. . . ,Xn free in e 

Lambda expressions {\ti . . . tn ~> e) are supported as syntactic sugar. Lambda 
lifting [Joh85] is used to translate them into global functions. 

The set of free variables of an expression e is given by the following definition. 

fv{x) = {4 
fv{c) = fv{f) = 0 

fv{ei 62) = fv{ei) U fv{c 2 ) 
fv{let Xi,...,Xn free in e) = fv{e) \ {tCi, . . . , Xn} 

Curry employs a Hindley-Milner type discipline, therefore the expression ei 
in application ei 62 will always be an expression, that accepts an argument of 
the type of 62- 

Functions are defined by a set of conditional equations of the form 

where the argument patterns L are terms and the so-called guard g as well as 
the body e are expressions. A where clause may added to the right hand side of 
an equation to provide local definitions and fresh logic variables whose scope is 
the guard g and the body e of the equation. 

The addition function for natural numbers can be defined as follows. 

add Zero n = n 

add (Succ m) n = Succ (add m n) 

A conditional equation for the function / is applicable in an expression 
/ ei • • • e„ if each argument expression matches the corresponding pattern 
ti and the guard g is satisfied (see below). In that case the application is re- 
placed by the body of the function with all variables occurring in the patterns 
ti replaced by the expressions in the corresponding positions of the arguments 
Ci- If an argument expression contains an unbound logic variable at a position 
where a constructor term occurs in pattern U, the variable is either instantiated 
with the corresponding pattern (narrowing) or the evaluation of the expression 
is suspended until this variable is instantiated by other parts of the program 
(residuation) . 

The evaluation strategy to be used by a function / can be specified with an 
evaluation annotation / eval r, where r is either flex or rigid. In the former 
case / uses narrowing, in the latter case / uses residuation. Curry provides 
reasonable defaults depending on the result type of the function, so that the 
evaluation strategy rarely needs to be specified explicitly. In particular, functions 
with result type Success (see below) use narrowing, while all other functions 
use residuation. 
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2.1 Constraints 

Curry has limited support for constraint solving. Expressions of type Success 
are checked for satisfiability. The predefined nullary constraint success is an 
expression that is always satisfied. 

Constraints may be composed with the binary operator (&) , which denotes 
the concurrent conjunction of two constraints. An expression e\ & 62 is satisfied 
if both expressions ei and 62 are satisfied. The order of evaluation of the two 
arguments is unspecified, Ci may be evaluated before 62 or vice versa or both 
expressions may be evaluated in some interleaved order. 

Finally, the kernel of Curry provides equational constraints. An equational 
constraint ei =; = 62 between two arbitrary expressions (of the same type) is 
satisfied if both arguments can be reduced to the same finite data term. If ei or 
62 contain unbound logic variables, an attempt is made to unify both expressions 
by instantiating variables to terms. If the unification succeeds, the constraint is 
satisfied. 

Note that Curry distinguishes between constraints (of type Success) and 
boolean expressions (of type Bool). While the former are checked for satisfiabil- 
ity, the latter reduce to the predefined constant terms True or False. 

Strict equality between terms is implemented by the boolean operator (==). 
An expression ei == 62 reduces to True if both expressions ei and 62 reduce 
to the same finite data term and False otherwise. If the arguments contain 
unbound variables, the evaluation is delayed until these variables are sufficiently 
instantiated. In terms of a concurrent constraint language, (=:=) corresponds 
to a tell and (==) to an ask constraint. 

Usually, predicates (in the sense of Prolog) are implemented as functions with 
result type Success in Curry. These function use narrowing by default and, thus, 
may instantiate unbound variables in their arguments. 

A predicate that is satisfied for all even natural numbers can be defined as 
follows in Curry. 

even Zero = success 

even (Succ (Succ n)) = even n 

A guard expression in a conditional equation must be either of type Success 
or of type Bool. An equation / U • • • I g = e is reduced to e in an applica- 
tion / ei . . . e„ only if the arguments ei, . . . , e„ can be matched with the terms 
ti, . . . ,tn and if the guard g is satisfied. If the guard expression is of type Bool, 
the expression is satisfied if it reduces to True. 

2.2 Floating point numbers 

In order to implement linear constraints over real numbers, we will assume the 
existence of a type Float representing floating-point numbers.^ We will also 
assume the existence of primitive arithmetic operations and relations between 
floating-point numbers. 

^ Floating-point nnmbers are not provided by the kernel of Curry 
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(+) , (-) , (*) , (/) : : Float -> Float -> Float 

(<) , (>) , (<=) , (>=) : : Float -> Float -> Bool 



2.3 Semantics 

The operational semantics of Curry can be given by a one-step reduction relation 
1 -^, between states of a computation. A state s is a pair consisting of a constraint 
<j) and an expression e. A sequence sq Sn of zero or more reduction steps 

with Vi C {1, . . . , n} : Si-i i— > Si will be abbreviated as sq Sn- 

A constraint is either the trivial constraint T, an inconsistent constraint T, 
a conjunction (/>i A (j )2 of two constraints 4>\ and </>2, or an equality constraint 
X = t, where x is a variable and t is a data term. 

(/) ::= T I T I (/)i A </>2 I a; = t 

The set of constrained variables in a constraint is defined inductively as follows. 

cu(T) = cu(T) = 0 

cv{4>i A 4>2) = cv{4>i) U cv{ 4>2) 
cv{x = t) = {a;} U vars{i) 

A state s = {(j), e) is in solved form if e is a data term and (j) ^ A- . 

A derivation of state sq is a sequence of one-step reductions sq A 

derivation sq s„ is sueeessful, if the state is in solved form. A derivation 
fails, if So Sn such that Sn = (T, e) for some arbitrary expression e. A deriva- 
tion So Sn flounders, if s„ = {4>,e) is not in solved form, (/) T, and Sn is 
h-^-irreducible. 



3 Linear constraints over Real Numbers 

A linear expression is either a real number a, a variable x, the product of a 
number and a variable, or a sum of linear expressions. 

I ::= a \ X \ a ■ x \ I + I 

A linear constraint is an (in-)equality between two linear expressions. It can 
always be transformed into the form 



aiXi + 02X2 H + OnXn 6 b 

where all Oi and b are real numbers, the Xi are pairwise distinct variables and 6 is 
a relation from the set {=, <, >,<,>}. In the case of real numbers, Gaussian 

elimination can be used to solve linear constraints involving only equalities and 
the simplex algorithm can be used, if inequalities are included. An algorithm to 
handle disequalities was presented in [IvH93]. 
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Fig. 1. A simple task graph 



As an example for the application of linear constraints we will consider 
scheduling problems. A scheduling problem can be described by a task graph, 
where each task is represented by a box containing the name and the duration 
of the task. Arrows between the tasks impose an order where each task at the 
base of the arrow must be finished before the task at the tip of the arrow may 
start. A simple example is shown in Fig. 1. This task graph corresponds to the 
following set of inequalities, where each variable represents the time at which 
the corresponding task begins. 

a + 3 <b b+1 < e c + 3</ e + l< end 

a + 3<c c + 3<e d + 2 < f / + 3< end 

a + 3 < d 



4 Linear constraints in Cnrry 

In order to integrate linear constraints over real numbers into Curry we have to 
allow for linear constraints in computation states. 



(j) \ a\Xi + 02 X 2 + • • • + 6 b 

The definition of the set of constrained variables has to be extended by a case 
for linear (in)equalities, too. 



Cv{aiXi + U2X2 H + anXn S b) = {xi , . . . , Xn} 

We assume a constraint solving mechanism 1 — which simplifies the current 
constraint. 

New constraints are added with the binary operators 

(=:=) : : a -> a -> Success 

:: Float -> Float -> Success 
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, , , , id), success) if oi < 02 

(0,ai<:=O2) ^ ; 

(_L,ai<:=a2) otherwise 

(x = a A 4 >,a<: =e) (<))', e') (x = a A 4 >,e<: =a) {(f>' , e!) 

{x = a A 4 >,x<\ =e) (()>', e') (x = a A 4 >,e-<- =x) (<))', e') 

aiaii + . . . + anXn - hyi - ... - bmym < bp - ap A (f) -L 
{(f>, ao+ai*xi+ . . . +an*Xn<-=bo+bi*yi+ ... +6 
(-L, 00+01**1+ . . . +a„*x„<:=bo+bi*yi+ ... +6 m *ym'} 

Ol*l + . . . + o„*„ — biyi — ... — bml/m < feo — Oo A </> (j)' 



{(j>, Oo + 01**1+ . . . +O„**„<:=6o + bl*2/l+ . . . +bm*ym) ^ ( 0 ', 



success) 



(0, /eii . . . eij) 



(0, /C21 . . . e2fc) (<)>', 62) 



if ())‘ 



(0, /eii . . . eij<:=e2) { 4 >' , e\<-.=ei) {(j>, ei<:=/e2i . . . 62 k) 

{(j),ei[xi/yi, . . . ,*„/t/„]<:=e2) {4>',e') 



{4>',ei<-.=e'^) 



(()), (let *1, ...,*„ free in ei)< : =62) (<()', e') where j/i ,..., 

(0,ei<:=e2[*i/r/i,..., *„/!/„]) 1-^ (</>', e') are fresh variables 

{ 4 >, ei< :=(let *1, . . . , *„ free in 62)) { 4 >\ ^') 



(NUM) 

(VAR) 

(LINl) 

(LIN 2 ) 

(FUN) 

(EX) 



Fig. 2. Semantics of ei < : = 62 



Here, (=:=) can enter either an equality constraint between terms to the con- 
straint store, e.g. x =:= Succ y, or a linear equality, e.g. x =:= y + 2*z. The 
other operators add a disequality or inequality constraint between linear expres- 
sions to the constraint store. ^ The semantics for the reduction of an expression 
Cl 8 62 can be defined inductively on the kind of argument expressions which can 
occur. Fig. 2 shows our semantics for the operator (<:=). The semantics of the 
other operators is defined analogously. 

With the help of these functions, we can now solve scheduling examples in 
Curry as follows. We use a list of logic variables to hold the time when the 
corresponding task begins. A dependency between two tasks is represented by 
a function which imposes a constraint between the two corresponding variables. 
E.g., the dependency between tasks A and B in Fig. 1 can be implemented by 
the following (anonymous) function. 

\[a,b] -> a + 3.0 <:= b 

A function which represents a schedule can be constructed incrementally 
from the dependencies between the tasks. E.g., the task graph in Fig. 1 can be 
implemented by the following function. 



We do not consider disequality constraints between terms in this paper. 



2 




192 W. Lux 



sample [a,b,c,d,e,f ,end] = 

mapC (after a 3.0) [b,c,d] & after b 1.0 e & 

mapC (after c 3.0) [e,f] & after d 2.0 f & 

after e 1.0 end & after f 3.0 end 

mapC f [] = success 

mapC f (x:xs) = f x & mapC f xs 

after xdy=x+d<:=y 

If we want to compute a solution which satisfies such a schedule, given 
some arbitrary start time, it can be computed by instantiating the variables 
with floating-point numbers. If the head of the list of variables corresponds to 
the initial task, a naive approach would be to compute valid schedules non- 
deterministically with the function schedule. 

solution schedule start 1 = 

schedule 1 & head 1 =:= start & mapC (enumerate start) (tail 1) 

enumerate 1 x = x = : = 1 

enumerate 1 x = enumerate (1 + 1.0) x 

head (x:xs) = x 
tail (x:xs) = xs 

5 Optimal solutions 

Usually the programmer is interested in finding an optimal solution admissible 
for a variable with respect to a given set of constraints. 

A naive approach would be to use Curry’s encapsulated search [HS98] for 
this purpose. Using the predefined function once which employs a depth-first 
strategy and returns only the first solution, a minimal schedule for our sample 
task graph can be computed as follows. 

once (solution sample 0.0) A (0.0, 3. 0,3. 0,3. 0,6. 0,6. 0,9.0) 

However, this approach is problematic. The enumerate function generates an 
infinite number of bindings for its arguments. If the arguments are instantiated in 
the wrong order, e.g. if we had reversed the list of variables, the above goal would 
never terminate. Thus, we also have to compute a reasonable upper bound for 
the schedule in question and pass this upper bound as an additional argument to 
solution and enumerate. Even then, the efficiency of the program will depend 
crucially on the order in which the variables are instantiated. 

Another problem with the approach of enumerating solutions is that it works 
only in the case where the durations of tasks have a common denominator. 

These problems are due to the fact, that the program uses the constraints 
only to check the satisfiability of a generated solution. However, the simplex al- 
gorithm, underlying the implementation of linear constraints over real numbers. 
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not only allows to check a set of linear equations for consistency, but also to 
compute an optimal solution for them. We, therefore, propose to provide also 
functions minimize and maximize, which compute the minimum or maximum 
of an expression with respect to a set of constraints. For the rest of this section 
we will consider only minimizations, the case of maximizations is analogous to 
this one. 

One has to be careful in the definition of these functions, though. A naive 
approach would be define minimize as a function of type 

minimize ; : Float -> Success 

with the intention that an expression minimize e minimizes the value of the 
expression e with respect to the current set of constraints. For instance, the 
expression 

let X free in x >:= 0.0 & minimize x 

would bind the variable x to the number 0.0. 

Unfortunately, such a definition of minimize destroys the declarative reading 
of the program. Consider the expression 

let X free in x >:= 0.0 & minimize x & x >:= 1.0 

If the constraints in the concurrent conjunction are evaluated from left to right, 
the expression fails, because x is first minimized with respect to the constraint 
X > : = 0.0 which binds x to the value 0 . 0. Under this binding the constraint 
X > : = 1.0 cannot be satisfied. On the other hand, if the constraints are evalu- 
ated from right to left, the expression is satisfiable and binds x to 1 . 0.^ 

The problem with the naive approach is that the variables occurring in the 
constraints may be affected by constraints in other expressions of the program. 
Thus, in order to control which constraints to take into account for the mini- 
mization, these constraints must become an explicit argument of the minimize 
function. In addition, the variables over which the minimization should take 
place have to be abstracted. Thus, minimize now becomes a function of type 

minimize : : (a -> Success) -> (a -> Float) -> a -> Success 

where minimize g/x succeeds if the constraint gx can be satisfied and x is 
bound to a value for which / x becomes minimal. If either f or g are non- 
deterministic functions, a minimal solution will be computed non-deterministi- 
cally for each possible solution oi f x and gx. In order to give a sound semantics 
to minimize the function must not constrain any of the free variables of / x or 
gx. 

In order to present our semantics of minimize g/ a;, we use an auxiliary 
function h which does not occur in the program and is defined by the conditional 
equation 

hx I gx = f X 

® Similar problems are known for CLP{?ft) implementations, e.g. Sicstus Prolog 
[CWA+95]. 
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For the operational semantics of minimize we have to distinguish three cases. 
First, the evaluation of hy, where y is a fresh variable, may fail. In that case the 
minimization will fail as well. 



(T, let y free in hy) (_L, e) 

{()>, minimize g f x) i— > (_L, minimize g/x) 



(FAIL) 



If the evaluation of h y, where y is a free variable, reduces to a floating-point 
number, the expression f y is obviously independent of the value of y. Therefore, 
minimize y/ a: reduces to success in this case. Still, the minimization may fail 
because the constraints imposed by g on its argument may be incompatible with 
those already present for x. 



(T, let y free in hy) (0', a) (j) A (j)' A {x = y) i— cv{(j)) C\cv{4>') = % 
{4>, minimize g f x) i— > ((/)", success) 

(NUM) 

The condition cv{4>) n cv{(j)') = 0 will ensure that no constraints for the free 
variables in hy have been added to the constraint store 4>' . 

Finally, ii hy reduces to a linear expression, minimize y/ a; succeeds if a 
minimum exists for hy. 

(T, let y free in hy) {(j)' , gq -b aia;i -b . . . + ajXj) 

cv{(j)) n cv{(j)) — 0 min{4>' , ao + aiXi -b . . . + ajXj,y) = T 

(()), minimize y / a;) i— > (T, minimize y / a;) 

(T, let y free in hy) {4>',ao + aia;i -b . . . -b cijXj) (LIN) 

(j) A (j)' A {x = z) I— (j)” cv{(j)) n cv{4>) = 0 

min{4> , ao + aiXi -b . . . -b ajXj,y) = z 
{(j), minimize g f x) i— > (())", success) 

The auxiliary functions min computes the minimum for the linear expression e 
under the constraints </> 

{ t a 4> A (y = z) ^ 1- and 

,3 : z A (y = t ) ^ T) A A c\,p^y—z 

T otherwise 



Here the notation e\(j, denotes the value of e in the context of the constraint 4>. 

With our new definition of minimize, the previous example can be written 
as follows: 



minimize (\x -> x >:= 0.0) (\x -> x) x & x >:= 1.0 

It is now apparent from the code that x should be minimized with respect to 
the constraint X >:= 0.0. 

If the constraint function has more than one solution, a minimum will be 
computed non-deterministically for each solution of y. E.g., for 





px=x>:=0.0 

px=x>:=1.0 
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the expression minimize p (\x -> x) x has two solutions which bind x to 0 . 0 
and to 1.0, resp. 

In order to hnd minimal solutions to a non-deterministic constraint function 
like p above, Curry’s encapsulated search can be used. This has the advantage of 
giving the programmer the chance to use the best suited strategy to prune the 
function’s search space instead of using a hxed strategy. For instance, a simple 
branch-and-bound strategy with depth first traversal, which is sufficient to find 
the minimal solution for p, can be coded in a few lines of Curry. 

min g m = bb m [] (try g) 

where bb m (g:gs) [] = bb m gs (try g) 

bb m gs [g] = 

minimize g id m’ & 

bbl m m’ (map (inject (\x -> x <: m’)) gs) [] 
where m’ free 

bb m gs’ (gl:g2:gs) = bb m (g2:gs ++ gs’) (try gl) 

bbl mm’ [] [] = m=:=m’ 

bbl m m’ (g:gs) [] = bb m gs (try g) 

bbl m _ gs [g] = 
minimize g id m’ & 

bbl m m’ (map (inject (\x -> x <: m’)) gs) [] 
where m’ free 

bbl mm’ gs’ (gl:g2:gs) = bb m (g2:gs ++ gs ’ ) (try gl) 
inject pqx=px&qx 

The function min makes use of the primitive search operator try. This function 
takes a single argument, the search goal, which is itself a unary function of type 
a -> Success. The argument of the search goal is normally used to constrain a 
goal variable the solutions of the goal. The result of try is either an empty list, 
denoting that the reduction of the goal has failed, or it is a singleton list contain- 
ing a function \x -> g, where g is a satishable constraint (in solved form), or 
the result is a list with at least two elements if the goal can be reduced only by 
a non-deterministic computation step. The elements of this list are search goals 
that represent the different alternatives for the reduction of the goal immediately 
after this non-deterministic step. 

The local functions bb and bbl perform a pattern matching on the result 
of evaluating the application try g. If an empty list is returned, i.e. g has no 
solution, the goal g can simply be discarded and bbl proceeds with the next 
goal or returns the minimum if there are no remaining goals. The function bb is 
undefined in this case because it corresponds to the case where the initial goal 
to min is undefined. 

If a single solution is found, bb and bbl use the minimum value for that solu- 
tion to prune the search space. This is done by adding the additional constraint 
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to the remaining search goals that their solution must be less than the current 
minimum. 

Due to the lazy evaluation of search spaces, the function min will not only 
compute the minimal solution for p but also for a variant of p where the second 
branch leads to an infinite computation: 

q X = X >:= 0.0 
qx=x>:=1.0&qx 

For this function, the evaluation of min q x will succeed and bind x to 0.0. 
Instead of using a simple depth-hrst traversal more complex functions can be 
used in order to ensure the termination in all cases if a minimum exists. 



6 Implementation 

6.1 Interface 

For the integration of linear constraints into our abstract machine [Lux99] , we 
assume that the constraint solver implements an interface with the following 
functions 

tell : LinCstrt x CStore CStore U {_L} 

ask : LinCstrt x CStore — > { True, False, Unknown} 

clone : CStore CStore x CStore 

minimize : LinExpr x CStore — > LinCstrt U {_L} 

maximize : LinExpr x CStore LinCstrt U {_L} 

The tell function adds a new linear constraint I to the constraint store cs. If 
the store remains consistent after adding the constraint I to the store, the new 
state of the constraint store is returned, otherwise the computation fails. The 
ask function is used to check the entailment of the linear constraint I by the 
constraint store cs. 

The clone operation duplicates the current state of the constraint store. This 
is necessary for the implementation of the encapsulated search, where different 
solutions may operate on different sets of constraint in parallel. In order to avoid 
flooding the heap with many identical copies of the constraint store, the actual 
copying of the store can be delayed until the store is actually modified. 

Finally, the minimize and maximize functions minimize or maximize a linear 
expression with respect to the constraints in the store. If a minimum exists, 
the bindings of all variables occurring in the expression are returned as linear 
constraints. If the linear expression is not bounded by the constraints, this list is 
empty. If the expression is bounded but no optimum exists, e.g. for the expression 
X and the constraint x > : 0.0, the functions fail. 

6.2 Representation of linear expressions 

The code for the function (< : =) and the other floating-point constraints, invokes 
the tell interface function in order to add a new constraint to the constraint 
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store. Unfortunately, the arguments to (<:=) will rarely be linear expressions. 
Thus, in order to pass a valid constraint to the solver, the code for (<:=) first 
has to scrutinize the arguments. This may involve the evaluation of suspended 
applications, e.g. if the body of the following function is evaluated. 

f = g X y <:= h X 
where x,y free 

gxy=4.0* (x+y) 
h X = 2.0 * X 

In this example, neither the application g x y nor h x is a linear expression. 
Both can be reduced to the linear expressions 4x + 4y and 2a:, though. 

In order to implement this reduction, the abstract machine has to provide a 
special mode where it reduces a floating-point expression to a linear expression 
instead to normal form. This mode is turned on when an argument expression to 
the constraint functions (<:=) etc. is evaluated. In linear expression reduction 
mode, only the implementation of the primitive functions (+), (-), (*), and 
(/) has to change, all other functions are left unchanged. 

As our machine uses a tagged representation for nodes in the heap, an easy 
solution would be to add just a new tag to represent linear expressions. However, 
this would mean that all other functions using floating point numbers would also 
have to handle this new tag. If such a function expects a floating point number 
as an argument (e.g. the function sin) and is passed a linear expression as 
an argument, the evaluation must be suspended until all variables occurring 
in the expression are instantiated to floating point numbers. Exactly the same 
will happen if the argument to sin is a suspended application whose evaluation 
is delayed. Thus we have chosen to represent linear expressions as suspended 
applications, too. 

A suspended application is mostly a closure node which includes information 
about the function to be evaluated and the arguments to which the function is 
applied. An additional flag is introduced to signal that this closure is a linear 
expression. This flag will be set by the arithmetic operations (+), (-), (*), and 
(/) if they cannot evaluate their arguments to floating point numbers but only 
to linear expressions and the result of the operation is still a linear expression. 

Thus, the evaluation of the suspended application x+y in linear expression 
reduction, where x or y is an unbound variable, returns the closure node for 
x+y itself with the linear expression flag set. In order to prevent other functions 
from repeatedly trying to reduce this suspended application to normal form, the 
lock bit of the closure is set as well. This bit used to signal that some thread 
is already evaluating the closure. In fact, (+) also must provide some (delayed) 
thread capable of continuing the evaluation of x+y once x or y are instantiated 
to a floating-point number. 

The code for ( + ) is a little bit more involved because it may have to trans- 
form its input in order to return a linear expression. E.g. when the application 
4.0* (x+y) is evaluated, the corresponding closure is not a linear expression. 
However, it can be turned into a linear expression by distributing the multipli- 
cation into the sum x+y. 
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Our implementation strategy smoothly fits with non-linear constraints in an 
expression. The evaluation of a non-linear constraint is automatically delayed 
until it becomes linear by the instantiation of variables in other parts of the 
program. For instance, in the expression 

sin (4.0 * (4.0 * x)) <:= y & x =:= 0 

the evaluation of the non-linear constraint sin(4.0*(4.0*x))<:=y is delayed 
until the variable x is bound to zero by the second constraint. 

Note that our strategy incurs no further cost on any function other than 
the primitive floating-point operations, because these functions must check for 
a ground result after evaluating a suspended application, anyway. 



7 Related work 

Constraints over real numbers have been implemented in a logic programming 
language for the first time in Prolog III [Col87] and CLP (3?) [JMSY90]. Many 
other Prolog implementations since then include a constraint solver for linear 
constraints over real numbers or for other constraint domains. 

Constraint solving has been integrated into functional-logic languages. Oz’s 
evaluation model [Smo95] is based on concurrent constraint solving. Oz does 
not support linear constraints over real numbers and does not implement opti- 
mization constraints. Instead, minimization and maximization have to be imple- 
mented with search operators. 

The Toy system [LH99] includes disequality constraints between syntac- 
tic terms and linear constraints over real numbers [AHLU96]. However, they 
consider only arithmetic constraints but not optimizing constraints. The imple- 
mentation of T Oy is based on a translation into Prolog and uses the constraint 
solving facilities of the underlying Prolog implementation. 

The problem to give a declarative semantics to optimization constraints has 
been addressed by Marriott and Stuckey [MS93] and Fages [Fag93] in the con- 
text of constraint logic programming. Their semantics is not limited to con- 
straints over real numbers and computes an optimal solution for all solutions 
of a non-deterministic goal. Thus, their implementation must include a general 
mechanism to prune the search space of a goal. In the context of Curry there 
is no need to include a search strategy in the implementation of optimization 
predicates because strategies can be implemented using the encapsulated search. 
This will allow the user to select a strategy which is best suited to the problem 
domain, while the approaches of Marriott and Stuckey as well as Fages have to 
use a fixed strategy. In addition, we think that the use of higher order constraints 
like minimum fits more nicely into the framework of a language which has support 
for higher-order functions and predicates. 

In earlier work [LuxOO] , we proposed to introduce a constraint solving monad 
C in order to integrate optimization constraints into Curry. While this approach 
will give a declarative semantics for the optimization constraints, it forces ev- 
ery computation involving minimizations or maximizations to be lifted into the 
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C-monad. This introduces a dichotomy between the constraints introducing lin- 
ear inequalities and those computing optimal solutions. In particular, this will 
complicate the use of optimization predicates in the context of the encapsulated 
search. With the approach presented in this paper, the optimization constraints 
have a clean declarative semantics and may be used in all places where other 
constraints can be used. 

8 Conclusion and Future Work 

In this paper we have sketched an integration of linear constraints over real num- 
bers into the functional logic language Curry. In particular we have considered 
optimization predicates which are highly useful in practice because often the 
user is interested in an optimal solution to a given problem. 

The semantics of optimization predicates has been studied in the context of 
constraint logic programming. However, in the case of Curry an implementation 
is considerably simpler because in the domain of real numbers there are known 
efficient algorithms which compute optimal solutions. In general, pruning tech- 
niques must be used to hnd an optimal solution for a given goal. In the context 
of Curry this is best handled by using search strategies implemented with the 
encapsulated search, i.e. within the language. 

Future work will concern the implementation of optimization constraints 
within the framework of our abstract machine. In addition, we will study the 
integration of other constraint domains into our system. 
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Abstract. This paper is concerned with the lazy conditional narrow- 
ing calculus LONG. In an earlier paper we proved that this calculus is 
complete with respect to normalizable solutions for the class of conflu- 
ent but not necessarily terminating conditional rewrite systems without 
so-called extra variables in the conditional parts of the rewrite rules. 
Unfortunately, the proof does not provide any useful complete selection 
function, hence in implementations we need to backtrack over the choice 
of equations in goals in order to guarantee that all solutions are enumer- 
ated. This is in contrast to the unconditional case where completeness 
with respect to the leftmost selection function is known. In this paper we 
close the gap by proving the completeness of long with respect to the 
leftmost selection strategy for the above-mentioned class of conditional 
rewrite systems. 



1 Introduction 

Narrowing (Fay [5], Hullot [16]) was originally invented as a general method for 
solving unification problems in equational theories that are presented by con- 
fluent term rewriting systems (TRSs for short). More recently, narrowing was 
proposed as the computational mechanism of several functional-logic program- 
ming languages (Hanus [13]) and several new completeness results concerning 
the completeness of various narrowing strategies and calculi have been obtained 
in the past few years. Here completeness means that for every solution to a given 
goal a solution that is at least as general is computed by the narrowing strat- 
egy. Since narrowing is a complicated operation, numerous calculi consisting of 
a small number of more elementary inference rules that simulate narrowing have 
been proposed (e.g. [6, 15, 20, 25, 14, 23, 8, 24, 19]). 

In this paper we consider the lazy conditional narrowing calculus LONG of 
Hamada and Middeldorp [11]. LCNC is the extension of the the lazy narrowing 
calculus LNC to conditional TRSs (CTRSs for short). Completeness issues of LNC 
have been extensively studied in [23] and [22]. In [23] Middeldorp et al. prove 
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that LNC is strongly complete whenever basic narrowing (Hullot [16]) is complete. 
Strong completeness means that the choice of the equation in goals can be made 
don’t care non-deterministic, resulting in a huge reduction of the search space as 
well as easing implementations. For the completeness of basic narrowing several 
sufficient conditions are known, including termination. It is also shown in [23] 
that LNC is complete for arbitrary confluent TRSs and normalized solutions 
with respect to the selection function 5ieft that selects the leftmost equation 
in every goal. (For this general class of TRSs, LNC is not strongly complete 
[23, Counterexample 10].) Based on the latter result Middeldorp and Okui [22] 
present restrictions on the participating TRSs and solutions which guarantee 
that all non-determinism due to the choice of inference rule of LNC is removed. 
The resulting deterministic calculus LNCd satisfies the optimality property that 
different derivations compute incomparable solutions for a class of TRSs that 
properly includes the class of TRSs for which a similar result was obtained by 
Antoy et al. in the setting of needed narrowing [1]. 

For the conditional version of LCNC much less is known. Hamada and Mid- 
deldorp [11] extended one of the main results of [23] to conditional rewriting: 
LCNC is strongly complete whenever basic conditional narrowing is complete. 
The latter is known for decreasing and confluent CTRSs without extra variables 
(Middeldorp and Hamoen [21]), terminating and level- confluent CTRSs with ex- 
tra variables in the conditions only (Giovannetti and Moiso [7]), and terminating 
and shallow-confluent CTRSs with extra variables (Werner [27]). In [12] two fur- 
ther completeness results are presented: (1) for confluent CTRSs without extra 
variables with respect to normalized solutions and (2) for arbitrary terminating 
and level-confluent systems. So the only known completeness result for LCNC 
that does not rely on some kind of termination assumption is (1). However, un- 
like its unconditional counterpart, the proof in [12] does not give completeness 
with respect to the leftmost selection function. As a matter of fact, the selection 
strategy used in the proof is not effective in that it refers to an ordinary condi- 
tional narrowing derivation computing the solution that we want to approximate 
with LCNC. Hence in implementations we need to backtrack over the choice of 
equations in goals in order to guarantee that all solutions are enumerated. This 
complicates implementations and, worse, leads to a dramatic increase in the 
search space, even more so since in conditional narrowing (whether presented 
as a single inference rule or in the form of a calculus like LCNC) the conditions 
of the applied rewrite rule are added to the current goal after every narrowing 
step. 

In this paper we strengthen result (1) to completeness with respect to the 
leftmost selection function. The non-trivial proof is based on a tricky variable 
condition that is preserved during an inductive transformation process. In order 
to benefit the reader who is familiar with our earlier completeness proofs (in [11, 
22, 23]), the current proof is structured in a similar way. We stress however that 
the key idea that makes the proof work is original to this paper. 

The remainder of the paper is organized as follows. In the next section we 
recall some definitions pertaining to conditional rewriting and we present the 
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calculus LCNC. In Section 3 we prove our completeness result. We make some 
concluding remarks in Section 4. 

2 Preliminaries 

We assume familiarity with the basics of (conditional) term rewriting and nar- 
rowing. Surveys can be found in [2,4, 18,21]. 

A conditional term rewriting system (CTRS for short) over a signature iT is a 
set TZ of (conditional) rewrite rules of the form I ^ r ^ c where the conditional 
part c is a (possibly empty) sequence si ~ ~ tn of equations. All 

terms l,r, Si, . . . , Sn,ti, . . . ,tn must belong to T(T,V) and we require that I 
is not a variable. Here V denotes a countably infinite set of variables. CTRSs 
are classified ([21]) according to the distribution of variables in rewrite rules. 
A 1-CTRS contains no extra variables (i.e., Var(r, c) C Var(Z) for all rewrite 
rules I ^ r c), a 2-CTRS may contain extra variables in the conditions only 
(Var(r) C Var(l) for all rewrite rules ? ^ r c), and a 3-CTRS may also have 
extra variables in the right-hand sides provided these occur in the corresponding 
conditions (Var(r) C Var(Z,c) for all rewrite rules ^ ^ r <f= c). 

Although extra variables enable a more natural and efficient style of writ- 
ing specifications or programs, their presence comes with a price. For instance, 
completeness results for narrowing that hold for arbitrary confluent TRSs and 1- 
CTRSs typically do not carry over to 2-CTRSs and 3-CTRSs without requiring 
some kind of termination assumption. In the next section we consider 1-CTRSs. 

We assume that every CTRS contains the rewrite rule a: « x — > true. Here 
« and true are function symbols that do not occur in the other rewrite rules. 
These symbols may only occur at the root position of terms. Let 72. be a CTRS. 
We inductively define unconditional TRSs TZn for n ^ 0 as follows: 

72() = {x ~ X ^ true }, 

72„+i = {W r0 \ I ^ r ^ c € TZ and c9 — T }. 

Here T stands for any sequence of trues. We define s t if and only if there 
exists an n ^ 0 such that s t- Our CTRS are known as join CTRSs in the 
term rewriting literature. 

An equation is a term of the form s « t. The constant true is also viewed as 
an equation. A goal is a sequence of equations. A substitution 0 is a (72-)solution 
of a goal G if s9 t9. This is equivalent to validity of the equations in G9 in all 
models of the underlying conditional equational system of TZ (Kaplan [17]) and 
for confluent TZ to G9 — T. We abbreviate the latter to 72 h G9. A normalized 
solution satisfies the additional property that variables are mapped to normal 
forms with respect to 72. 

For a substitution 9 and a set of variables W , we denote [W \ T>{9)) U J(0 [;y ) 
by Va.rw{9)- Here 'D{9) = {x £ V \ 9{x) ^ x} denotes the domain of 9, which 
is always assumed to be hnite, and I{9\’^) = Ua; 6 -D( 0 )nw 
variables introduced by the restriction of 0 to W . 
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The lazy conditional narrowing calculus LCNC (Hamada and Middeldorp [11]) 
consists of the following five inference rules: 

[0] outermost narrowing 

G , Si ~ ^ 1 , . . . , Sn ~ r ^ t^ C^G 

if there exists a fresh variant /(/i, . . . , — > r 4= c of a rewrite rule in 72., 

[1] imitation 

G^/(sl,.■.,s„)-a:,G" 

(G',Si « Xi, . . . , S„ « Xn,G")0 

if 0 = {a: I— > f{xi, . . . , Xn)} with Xi, . . . ,Xn fresh variables, 

[d] decomposition 

G',/(si,...,s„)^/(G,...,tJ,G" 

G',Si « G, • ■ • ,Sn « tn,G" 

[v] variable elimination 

G',s~x,G” 

{G',G")9 

\i X ^ Var(s) and 9 = {x ^ s}, 

[t] removal of trivial equations 

G',x«a:,G" 

G', G" ■ 

In the rules [o], [i], and [v], s ~ t stands for s « t or t « s. (Since the inference 
rules never produce the equation true, we assume that LCNC deals only with 
goals that do not contain true.) Note that the outermost narrowing rule is 
applicable as soon as the root symbol of one side s of an equation equals the root 
symbol of the left-hand side I of a rewrite rule. The parameter-passing equations 
Si « li, . . . ,Sn ~ In code the problem of unifying s and 1. Further note that 
unlike higher-order narrowing calculi (e.g. [24, 19]) we do not permit outermost 
narrowing at variable positions. This makes the task of proving completeness 
much more challenging but results in a much smaller search space. 

If G and G' are the upper and lower goal in the inference rule [a] (a G 
{o, i, d, V, t}), we write G G'. This is called an LCNC-step. The applied 

rewrite rule or substitution may be supplied as subscript, that is, we write things 
like G G' and G G'. A finite LCNC-derivation Gi 

Gn may be abbreviated to Gi G„ where 9 is the composition 9i ■ ■ ■ 9n-i of 
the substitutions 0i, . . . , 9n-i computed along its steps. An LCNC-refutation is 
an LCNC-derivation ending in the empty goal □. 
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3 Leftmost Selection 

This section contains our main result, the completeness of LCNC for arbitrary 
confluent 1-CTRSs with respect to normalized solutions and the leftmost selec- 
tion function 5ieft- So we assume that the sequence G' of equations to the left 
of the selected equation in the inference rules of LCNC is empty. 

In previous results ([11,12]) we reduced the (strong) completeness of LCNC 
(for a suitable class of CTRSs and solutions) to either the completeness of con- 
ditional narrowing or the completeness of conditional rewriting by means of an 
inductive transformation process. The advantage of rewriting is that rewrite 
steps applied to different parts of a goal or equation can be swapped at will, 
which greatly facilitates a proof of completeness with respect to a particular 
selection strategy. In the proof below we use the variant of conditional rewriting 
in which the list of instantiated conditions of the applied rewrite rule is explic- 
itly added to the goal after every rewrite step. Formally, we use the relation ^ 
defined as follows: G ^ G' if G = Gi, e, G 2 , e ^ e' by applying the conditional 
rewrite rule Z ^ r c with substitution 9 (so e' = e[ra]p for some position p 
in e and TZ h ccr), and G' = Gi, e', ca, G 2 . It is well-known ([3, 21]) that TZh G 
if and only if G T. We assume without loss of generality that in a rewrite 
proof G T always the leftmost equation different from true is selected. 

Similar to previous completeness proofs, we define a couple of basic transfor- 
mations on rewrite proofs II : GO T. In order to make the proof work, we 
need to keep track of a number of variables along the transformation process. 
Since these variables cannot be inferred from the current rewrite proof 7T, to- 
gether with G and 0, we need to enrich rewrite proofs. This is the reason why we 
consider quadruples, called states, of the form (G, 0, II, X) where G is a goal, 0 a 
solution of G, 7T : GO T a rewrite proof of GO, and X a finite set of variables 
associated to 77. Variables in X are said to be of interest and variables in G but 
not in X are called intermediate. In order to avoid confusion, we occasionally 
write X-intermediate or even ^-intermediate (when comparing different states 
with the same X). 

We require that the properties defined below are satisfied. 

Definition 1. A state If = {G,9, II, X) is called normal if 0\x normalized. 
We say that 77 satisfies the variable condition if for every equation s ~ t in 
G = G\,s ~ t,G^ the following three conditions hold: 

VCl all intermediate variables in s occur in G\ or all intermediate variables in 
t occur in G\ , 

VC2 if s9 is rewritten in 77 then all intermediate variables in s occur in Gi, 
VC3 if to is rewritten in 77 then all intermediate variables in t occur in Gi. 

A normal state with the variable condition is called admissible. 

Example 1. Consider the confluent 1-CTRS consisting of the rewrite rules 

f{x,y) g{y) ^ x^a 

a ^ b 
g{b) b 
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and the goal G = f{x,y) « g{y),g{g{yj) ~ a. We determine 9, II, and X such 
that n_ = {G,9,n,X) is admissible. First of all, since the variable y occurs 
in both sides of the leftmost equation f{x,y) « g{y), it must be a variable of 
interest for otherwise VCl is violated. So y G X and hence, to satisfy normality, 
0{y) should be a normal form. The only normal form that satisfies the second 
equation of G is b, with associated rewrite proof 

g{g{b)) « a ^ g{b) «a ^ b ^ a ^ ^ true. 

Since g{g{y)) ~ a does not contain intermediate variables, it satisfies VCl, 
VC2, and VC3. Likewise, since g{y) lacks intermediate variables, f{x, y) « g{y) 
satisfies VC3. The only way to solve this equation is by applying the first rewrite 
rule to its (instantiated) left-hand side. Hence, to satisfy VC2, x cannot be an 
intermediate variable. Consequently, x G X and thus to conclude that JJ is 
admissible it only remains to show that we can substitute a normal form for x 
such that the equation f{x, b) « g{b) is solvable. It is easy to see that we should 
again take the normal form b, with associated rewrite proof 

f{b,b)^g(b) ^ g(b) ~ g{b) ,b K a ^ true, 5 « a ^ true, & « 6 ^ T. 

An example of a goal without admissible states is f{x) « x with respect to the 
TRS consisting of the rule a f{a)- Note that f{x) « x has no normalized 
solutions. 

Lemma 1. Let 77 = (G, 9, 77, X) be an admissible state with G = s ~ t,H . 

1. If s9 is rewritten in 77 then s is not a variable and does not include inter- 
mediate variables. 

2. If t9 is rewritten in 77 then t is not a variable and does not include inter- 
mediate variables. 

Proof. We prove the first statement. Suppose the left-hand side of s9 « t9 is 
rewritten in 77. By VC2 all intermediate variables in s should occur in the 
equations to the left of s « 7 in G. Since s « 7 is the leftmost equation, there 
cannot be intermediate variables in s. Hence, if s is a variable then it must 
be a variable of interest and thus s9 is a normal form because If is normal. 
This however contradicts the assumption that s9 is rewritten in 77. The second 
statement is proved in exactly the same way (with VC3 instead of VC2). □ 

In the following transformation lemmata 77 denotes an admissible state 
(G, 0,77, A) such that G = s « 7,77 and, in Lemmata 2, 3, and 5, W denotes 
a finite set of variables such that Var(G) C W. Recall our earlier assumption 
that 77 respects 5ieft. In particular, in the first step of 77 the equation s « 7 is 
selected. 

Lemma 2. Let s = /(si, . . . , s„) and suppose that a reduct of s9 ^ t9 in II is 
rewritten at position 1. If I ^ r c is the employed rewrite rule in the first 
such step then there exists an admissible state 4>[o]{lL) = {G',9',II',X) with 
G' = s I, r Ks t,c,H such that 9' = 9 [W] . 
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Proof. The given rewrite proof II is of the form 

Ge lT^t',C,H0 ^ rr ^t',CT,C,He T. 

Here C are the instantiated conditions of the rewrite rules applied in the rewrite 
sequence from sO « t9 to It « t' . Without loss of generality we assume that 
Var(l ^ r <1= c) n (X U W) = 0 and T>{t) = Var(l ^ r c). Hence the 
substitution 0' = 0Ur is well-defined. Since I?(r) flW — 0, ff — 6 [W]. We have 
G'd' = s9 It, tt « tO, ct, HO. The first part of II can be transformed into 

G'9' lTK.lT,Gi,rTK.t9,CT,H9 

It ^lT,Gi,rT ^t',C2,CT,H9 
^ true, Cl, TT t' ,G 2 ,ct, H9. 

Here Ci,C 2 and C consist of the same equations in possibly different order. 
Hence by rearranging the steps in the remaining part of II we obtain 

true, Cl, TT ~ t' ,C 2 ,ct, H9 T. 

Concatenating these two derivations yields the rewrite proof II' . It remains to 
show that the state 4>[o\{lD = {G',9',II',X) is admissible. Since 9'\x = U 
= o\x, 4’[o] {LO inherits normality from If. For the variable condition we 
need some more effort. Below we make tacit use of the observation that a variable 
X G Var(s « t, H) is 77-intermediate in G if and only if x is 4\o\ 1771-intermediate 
in G' . First consider the equation s ~ 1. Since s9' is rewritten in 77', we obtain 
from Lemma 1(1) that s does not contain intermediate variables. Hence VCl and 
VC2 are trivially satisfied. By construction, the right-hand side of sff « 19' is 
never rewritten in 77'. Hence VC3 holds vacuously. Next consider the equations 
in r « 7, c. Because we deal with CTRSs without extra variables, all variables 
in r and c occur in I and hence the three variable conditions are true for the 
equations in c and r « 7 satisfies VCl and VC 2. Suppose the right-hand side 
of r9' « t9' is rewritten in II' . By construction of 77', this is only possible if the 
right-hand side of s9 « t9 is rewritten in 77. According to Lemma 1(2) 7 does 
not contain intermediate variables and thus the equation r « 7 in G' satisfies 
VC3. Finally, consider an equation s' « 7' in 77 — Hi,s' ~ 7', H 2 . Let Vi be the 
set of intermediate variables in s' and V 2 the set of intermediate variables in 7'. 
Since If is admissible, Vi C Var(s « 7, 77i) or V 2 C Var(s « 7, 77i). Hence also 
Vi C Var(s « 7,r « 7,77i) or V 2 C Var(s ^l,r ^ t,Hi). This proves VCl. The 
proof of VC2 is just as easy: If s'9' is rewritten in 77' then s'9 is rewritten in 
77 and thus all intermediate variables in s' occur in s « 7, Hi and therefore also 
in s « 7, r « 7, 77i. Finally, VC3 is proved in exactly the same way. □ 

Note that the above proof breaks down if we admit extra variables in the 
conditional rewrite rules. Further note that the proof remains valid if we would 
put the equation r « 7 after the conditions c in G'. 

Lemma 3. Let s = /(si, . . . , s„) and 7 G V. 7/root(70) = / then there exists an 
admissible state ^[i](77) = {G',9',H,X') with G' = Gcri such that ai9' = 9 [W]. 
Here (Ti = {7 1 — > f{xi , . . . , x„)} with xi,. . . ,Xn ^ W. 
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Proof. Write t9 = f{ti, . . . ,tn) and define 9' = 6 U {xi ti \ 1 ^ i ^ n}. One 
easily verifies that a\9' — 9 \W]. We have G'9' = Ga\9' = G9 and thus 7T is a 
rewrite proof of G'9' . We define X' = Ua;gxVar(a:(Ti). Equivalently, 

^ f(X\{t})U{a;i,...,a;„} iiteX, 

I X otherwise. 

It remains to show that {n) is admissible. First we show that 9' \x' is normal- 
ized. We consider two cases. If t G X thenff'l'jf' = i— > ti | I ^ ^ n}. 

The substitution 6*|'x\{t} i® normalized because 9\x is normalized. Furthermore, 
since every ti is a subterm of t9 and t9 is a normal form because 77 is normal and 
t £ X, {xi I— > ti I 1 ^ i ^ n} is normalized as well, li t ^ X then 9'\x' — 9\x is 
normalized by assumption. Next we show that every equation in G' satisfies the 
variable condition. Again we consider two cases. 

1. Suppose that t £ X. Then Xi,. . . ,Xn belong to X' and thus the right-hand 
side tai = f{xi, . . . ,Xn) of the leftmost equation sai « tax in G' does 
not contain A'-intermediate variables. Hence stJi « tai satisfies VCl and 
VC3. Suppose sai9' is rewritten in 77. Then, as 77 is admissible, s does not 
contain A-intermediate variables. We have to show that scri does not contain 
A'-intermediate variables. Since the variables X\, ... ,Xn are of interest, it 
follows that every A'-intermediate variable in scti is A-intermediate in s. 
Therefore sai « tai satisfies VC3. 

Next consider an equation s'ai « t'ai in Hai — {Hi, s' « t',H 2 )ai. Let 
Vi be the set of A'-intermediate variables in s'a\ and V 2 the set of A'- 
intermediate variables in t' a\. Since the variables Xi,...,Xn are not A'- 
intermediate and t is not A-intermediate, Vi (V 2 ) coincides with the set of A- 
intermediate variables in s' {t'). Since 77 is admissible, Vi C Var(s « t,Hi) 
or V 2 C Var(s « t,Hi). Because t ^ Vi U V 2 , Vi C Var((s « t,Hi)ai) or 
V 2 C Var((s « t,Hi)ai). This concludes the proof of VCl. Next we prove 
VC2. If s'a\9' = s' 9 is rewritten in 77 then V\ C Var(s « t,Hi) and as 
t ^Vi also Vi C Var((s « t, Hi)ai). The proof of VC3 is just as easy. 

2. Suppose that t ^ X. Then t is ff- intermediate and Xi, ... ,Xn are </>[i](77)- 
intermediate. First consider the equation scri « tai. Since t is intermediate, 
s cannot contain intermediate variables. In particular, t does not occur in s 
and therefore sai = s. So scri « tai satisfies VCl and VC2. Since t is a 
variable, ta\9' — t9 cannot be rewritten in 77 as a consequence of Lemma 1(2) 
and hence VC3 is satished too. 

Next consider an equation s'tJi « t'ai in Hai — {Hi, s' « t',H 2 )ai. Let 
Vi' {Vf) be the set of ^[i] (77)-intermediate variables in s'cri {t'ai) and let Vi 
(V 2 ) be the set of ^-intermediate variables in s' {t'). We have 

V' = I ■ • ■ ’ ^ ^ Var(s'), 

^ I Vi otherwise, 
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and 

V' = { • ■ • ’ ^ ^ Var(f'), 

1 V 2 otherwise. 

Because n_ is admissible, Vi C Var(s « t,Hi) or V 2 C Var(s « t,Hi). We 
consider the former. To conclude VCl it is sufficient to show that V[ C 
Var((s Rs t,Hi)ai). We distinguish two cases. If t € Var(s') then t £ Vi 
and thus Xi,. . . ,Xn £ Var((s « t,Hi)ai). Since we also have the inclusion 
bi \ {t} C Var((s « t,Hi)ai), V( C Var((s « t,Hi)ai) holds. If t ^ Var(s') 
then t ^ Vi and thus V{ = Vi C Var((s « This proves VCl. 

For VC2 we reason as follows. Suppose s' <j\d' = s'd is rewritten in 77. This 
implies that Vi C Var(s « and hence V( C Var((s « t,Hi)ai) by 

using similar arguments as before. The proof of VC3 is again very similar. 

□ 

Lemma 4. Let s = /(si, . . . , s„), t = /(ti, . . . , tn), and suppose that no reduct 
of s9 Ki to in n is rewritten at position 1 or 2. There exists an admissible state 
4>[d]in_) = {G',0,n',X) with G' = Si KS ti, Sn ^ tn, H . 

Proof. The given rewrite proof 77 is of the form 

GO f{ui,...,Un)^f{ui,...,Un),G,HO ^ true, C, 776* T. 

Here G are the instantiated conditions of the rewrite rules applied in the rewrite 
sequence from sO « tO to f{u \, . . . , u„) « f{ui, ■ ■ ■ , Un). The first part of 77 can 
be transformed into 

G'O' u\ ~ ui,C\, . . . ,Un ^ Un,Cn, HO true. Cl ,..., true, 770. 

Here Ci, . . . , C„ and C consist of the same equations in possibly different order. 
Hence by rearranging the steps in the latter part of 77 we obtain 

true, Cl, ..., true, Cn, 770 T. 

Concatenating these two derivations yields the rewrite proof 77' of G'O. It re- 
mains to show that the state ^[d](il) = {G',0,H',X) is admissible. Since 1J_ 
has the same 0 and X, normality is obvious. Because H_ satisfies condition 
VCl, s or t does not contain intermediate variables. Hence there are no in- 
termediate variables in Si, . . . , or in t\, ... ,tn. Consequently, the equations 
Si K, ti, . . . , Sn ~ tn rn. G' satisfy VCl. The conditions VC2 and VC3 are also 
easily verified. For instance, suppose that UO is rewritten in 77'. Then, by con- 
struction of 77', to is rewritten in 77. According to Lemma 1, t does not contain 
intermediate variables and since ti is a subterm of t, U also lacks intermediate 
variables. By using similar arguments one easily verifies that the equations in 77 
satisfy the three conditions. □ 

Lemma 5. Let t £ V, s ^ t, and suppose that in the first step of H sO ^ tO 
is rewritten at the root position. There exists an admissible state </^v](iX) = 
(G', 0, 77', X') with G' = Ha\ such that a\0 = 0 \W]. Here cti = {t i— > s}. 
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Proof. Since s6 « t9 is rewritten to true by the rule x ~ x ^ true, we must 
have s9 = t9. Hence tai9 — s9 = t9. For variables y different from t we have 
yai9 = y9. Hence ai9 ^ 9 [W]. Since Var{H) C W, G'9 ^ Hai9 = H9 and thus 
from the tail of the rewrite proof U : 

G9 ^ true,^^ T 



we can extract a rewrite proof II' of G'9. We define X' = Ua;gjfVar(a:cri). Clearly 



W = 



{X \ {t}) U Var(s) 



ift€X, 

otherwise. 



It remains to show that </>[v](iI) is admissible. First we show that 9\x' is nor- 
malized. We consider two cases, li t € X then 9\x> = ^fjc\{t}uvar(s)- The sub- 
stitution is normalized because 9\x is normalized. If x G Var(s) then x9 

is a subterm of s9 — t9. Since t9 is a normal form by the normality of If, so is 
x9. Hence ^tvarls) is normalized as well, li t ^ X then 9\x' — 9\x is normalized 
by assumption. Next we show that every equation in G' satisfies the variable 
condition. Let s'ai « t'ai be an equation in Hai = {Hi, s' « t',H 2 )cri. Let V{ 
(Vf) be the set of ^'-intermediate variables in s'ai {t'ai) and let Vi (V 2 ) be the 
set of intermediate variables in s' {t'). We consider two cases. 

1. Suppose that t G X. Then Var(s) C X'. So the variables in Var(s) are not 
^'-intermediate and t is not X-intermediate. It follows that V( = V\ and 
Vf = V 2 . Since 77 is admissible, Vi C Var(TLi) or V 2 C Var(TLi). Because 
t ^ Vi U V 2 , V( C Var(7Li(Ti) or Vf C Var(77iai). This concludes the proof 
of VCl. The proofs of VC2 and VC3 also easily follow from the identities 
V{ = Vi and Vf = V 2 and the fact that t ^ Vi U H 2 . 

2. Suppose that t ^ X. Then t is 77-intermediate and all variables in Var(s) 
are (7T)-intermediate. We have 



and 






(Ti \ {7}) U Var(s) 
Vi 



if 7 G Var(s'), 
otherwise. 



^2 



{V 2 \ {7}) U Var(s) 
V2 



if 7 G Var(7'), 
otherwise. 



Because If is admissible, Vi C Var(77i) or V 2 C Var(77i). We consider 
the latter. To conclude VCl it is therefore sufficient to show that Vf C 
Var(77i(Ti). We distinguish two cases. If 7 G Var(7') then 7 G Vi and thus 
Var(s) C Var(77itTi). Since the inclusion Vi \ {7} C Var(77icri) also holds, 
Vf C Var(77i(Ji) as desired. If 7 ^ Var(7') then 7 ^ Vi and thus Vf = Vi C 
Var(77i(Ji). This completes the proof of VCl. The proofs of VC2 and VC3 
are based on similar arguments and omitted. 
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□ 



Lemma 6. Let t G V, s = t, and suppose that in the first step of II s0 « 
to is rewritten at the root position. There exists an admissible state fit] ilL) = 
{G',0,n',X) withG' = H. 

Proof. The given rewrite proof II has the form 

GO ^ true, HO T. 

From the tail of II we extract a rewrite proof II' of G'O = HO. It is easy to show 
that fiit]{]T) is admissible. □ 

Lemma 7. There exists an admissible state 0swap(ZI) = {G',0,H',X) with 
G' = t^s,H. 

Proof. The given rewrite proof 7T : (s « t,H)0 T is transformed into a 
rewrite proof H' of {t « s, H)0 by simply swapping the two sides of every reduct 
of sO ~ to. This clearly does not affect normality and since the variable condition 
is symmetric with respect the two sides of an equation it follows that fiswapilL) 
is admissible. □ 

We want to stress that swapping different equations (as opposed to the two 
sides of a single equation as in the preceding lemma) does not preserve the 
variable condition. This makes a lot of sense, since if it would preserve the 
variable condition then we could prove strong completeness of LCNC but from 
[23] we already know that the LNC is not strongly complete. 

In the proof of the main theorem below, we use induction on admissible states 
with respect to the well-founded order defined below. This order is essentially 
the same as the one used in the completeness proofs of [23, 12]. 

Definition 2. The complexity |il| of a state IT = {G,0,H,X) is defined as the 
triple consisting of (1) the number of rewrite steps in H at non-root positions, (2) 
the multiset \MVa.r{G)0\, and (3) the number of occurrences of symbols different 
from « and true in G. Here AtVar(G) denotes the multiset of variable occur- 
rences inG, andfor any multiset M = {t\,... ,t„} of terms, MO and\M\ denote 
the multisets {GO,... ,tnO} and {|ti|,... ,]t„l}, respectively. The well-founded 
order ^ on states is defined as follows: Ifi fh if \II]_\ lex(>, >mui, >) \ H 2 \. 
Here lex(>, >mui, >) denotes the lexicographic product of>, >mup and >. 

Lemma 8. Let If be a .state and a G {o, i, d, v, t}. We have IT ^ fi[a]{H_) 
whenever the latter is defined. Moreover, \H\ = ]^wap(il)|- 

Proof. Basically the same as the proof of Lemma 20 in [23] . For a = o we observe 
a decrease in the first component of \H\. Here it is essential that we work with 
^ instead of the ordinary rewrite relation — in this way steps that take place 
in the conditional part of the applied rewrite rule are already accounted for in 
\H\. For a G {i, d, v, t} the number of rewrite steps at non-root positions remains 
the same. For a G {i, v, t} the second component of |iT| decreases. For a = d the 
second component remains the same while the third component of |_H| decreases. 

□ 
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Theorem 1. Let TZ be a confluent CTRS without extra variables and G a goal. 
For every normalized solution 0 of G there exists an LCNC-refutation G =>■* □ 
respecting 5ieft such that a ^9 [Var(G)] . 

Proof. Because TZ is confluent, G9 admits a rewrite proof II. Consider the state 
n = {G,9, n, X) with X = Var(G). By assumption 0\x is normalized. Since 
all variables of G are of interest, G does not contain intermediate variables and 
hence the variable condition is trivially satisfied. Therefore iT is admissible. We 
use induction on the complexity of iT. In order to make the induction work we 
prove a ^ 9 [W] for a finite set of variables W that includes Var(G). The base 
case is trivial since G must be the empty goal (and thus we can take tr = e, the 
empty substitution) . For the induction step we proceed as follows. We prove the 
existence of an LCNC-step Fi : G G' that respects 5ieft and an admissible 
state IT = {G',9',n',X') snch that = 9 [IT]. Let G = s « t,H. We 
distinguish the following cases, depending on what happens to s9 « t9 in iT. 

1. Suppose no reduct of .s9 « t9 is rewritten at position 1 or 2. We distinguish 

five further cases. 

(a) Suppose s,t ^ V. We may write s = /(si, . . . , Sn) and t = /(G, . . . ,tn)- 
From Lemma 4 we obtain an admissible state 4>[d]{IL) = {G' , 9' , II' , X') 
with G' = Si « ti,...,s„ « tn,H, 9' = 9, and X' = X. We have 

: G =^>[d] G'. Take cti = e and IIf_ = 4>[d]{IIf}. 

(b) Suppose t G V and s = t. According to Lemma 1 no s9 and t9 are not 
rewritten and hence in the first step oi II s9 ~ t9 is rewritten at the 
root position. Hence Lemma 6 is applicable, yielding an admissible state 

= {G',9',n',X') with G' ^ H, 9' = 9, and X' = X. We have 

: G G'. Take ai = e and nf_ = (j)[t]{lD- 

(c) Suppose t G V, s t, and a reduct of s « t is rewritten at a non-root 

position. From Lemma 1 we infer that s is not a variable and moreover 
that t9 is not rewritten in TT. Hence we may write s = /(si, . . . , s„) and 
we have voot(t9) = f. Consequently, Lemma 3 is applicable, yielding an 
admissible state <('[i](iT) = {G" ,9” , II" , X”) with G" = Gcti, iT" = iT, 
and ai9" — 9 [W] for the substitution a — {t f{xi , . ■ . , Xn)}. We have 
G" = (/(si, . . . , s„) « f{xi, . . . ,Xn), H)ai. By assumption no reduct 
of scr9" « ta9" is rewritten at position 1 or 2. Hence we can apply 
Lemma 4. This yields an admissible state ^[d] {4>[i] {IL)) = {G' , 9', II', X') 
with G' = (si « xi, . . . , « Xn, H)(Xi, 9' — 9" , and X' = X" . We have 

: G G' and cri6»' = ai9" = 9 [IT]. Take Ilf = . 

(d) Suppose t G V, s t, and the first rewrite step takes place at the 
root position of s « t. Lemma 5 yields an admissible state 0[v](il) = 
(G', 9', iT', X') with G' = Ga, iT' = iT, and ai9' = 9 [IT] for the substi- 
tution a\ — {t^ s}. We have : G =^[v],<ri G' . Take IJf = 4>[v\{.lD- 

(e) In the remaining case we have t ^ V and s G V. This case reduces to 
case 1(c) or 1(d) by an appeal to Lemma 7. 
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2. Suppose a reduct of s9 « t9 is rewritten at position 1. Let I = f{h, . . . ,ln) ^ 
r c he the employed rewrite rule the first time this happens. From 
Lemma 2 we obtain an admissible state 4>io\{IL) = {G” ,9” , U” , X”) with 
G” = s ^ I, r ^ t, c, H, X" = X, and 9” — 9 [W]. According to Lemma 1, s 
cannot be a variable. Hence we may write s = /(si, . . . , s„). Let G" = Si « 
li, . . . ,Sn ~ ln,r « t,c,H. We have iFi : G =l>[o] G". Note that Lemma 4 is 
applicable to ^[o] (JT) since by construction no reduct of s9” « 19” is rewrit- 
ten at position 1 and 2. This results in an admissible state <p[d]{4>[o]iIL)) = 
{G',9',n',X') with 9' = 9” and X' = X. Clearly 9' = 9 [W]. Take cn = e 
andiT = 0[d](<^[o](fI))• 

3. Suppose a reduct of s9 « t9 is rewritten at position 2. This case reduces to 
the previous one by an appeal to Lemma 7. 

In all cases we obtain iT from 77 by applying one or two transformation steps 
4>[o], 0[d]) 4‘[t] together with an additional application of 0swap in case 

1(e) and 3. According to Lemma 8 11^ has smaller complexity than J. Let 
W' = Varw(cTi) U Var(G'). We have Var(G') C W' and thus we can apply 
the induction hypothesis to 77b This yields an LCNC-refutation iF': G' =!>*/ □ 
respecting 5ieft such that a' ^ 9' \W'\. Define a = a\a' . From a\9' — 9 [W], 
a' ^ 9' [IT'], and Varw(ui) C W' we infer that a ^ 9 [IF]. Concatenating 
the LCNC-step <Fi and the LCNC-refutation iF' yields the desired LCNC-refutation 
iF. □ 

4 Conclusion 

In this paper we showed that the lazy conditional narrowing calculus LCNC is 
complete for arbitrary confluent 1-CTRSs and normalized solutions with respect 
to the leftmost selection function. As we suggested in the text following Lemma 2, 
this result remains true if in the outermost narrowing rule [o] of LCNC we would 
interchange r « 7 and c in the new goal G' , S\ ~ h, . . . , Sn ~ InX ~ C c, G". Even 
with the restriction to 5ieft the search space of LCNC is still very large, owing 
mainly to the non-determinism due to the choice of the inference rule. We should 
investigate under what conditions we can eliminate this non-determinism. In the 
unconditional case this question has been fully answered ([22]), but it seems 
doubtful whether the same conditions work for arbitrary confluent 1-CTRSs. 
Nevertheless, the result presented in this paper is an important step towards 
a complete deterministic version of LCNC. In [10] Ida and Hamada present an 
implementation of LCNCd in the symbolic computation language Mathematica. 
LCNCd is the conditional counterpart of the deterministic calculus LNCd ([22]) 
and incorporates leftmost selection. It is unknown for which classes of CTRSs 
and solutions this calculus is complete. (No completeness results are reported in 
[ 10 ].) 

Our result answers affirmatively one of the two open problems mentioned in 
[12]. The other open problem refers to the following completeness result of [12] 
that we already mentioned in the introduction: LCNC is complete for arbitrary 
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terminating and level-confluent 3-CTRSs. Level-confluence is a stronger notion 
than confluence but sufficient syntactic criteria are known ([26]). The proof of 
this result in [12] relies on a complicated selection function which is not effective. 
In particular, completeness with respect to the leftmost selection function is 
unknown and it is even open whether or not LCNC is strongly complete for 
terminating and level-confluent 3-CTRSs.^ 

R is worthwhile to obtain completeness results (for LCNC as well as for ordi- 
nary conditional narrowing) for CTRSs with extra variables that do not rely on 
some kind of termination requirement. Examples in [21,11] show that this is a 
highly non-trivial task. 
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Abstract. CLNC is a lazy narrowing calculus for goal solving in the 
context of CRWL, a rewriting logic for functional logic programming 
that deals with non-deterministic functions. The JUMP-machine is an 
abstract machine model for the efficient implementation of functional 
logic languages. In this paper, we propose the integration of these two 
abstract models into an experimental system, for which extensibility and 
modihability are major concerns. This leads us to the selection of an 
object-oriented approach and the use of design patterns for the system 
design and implementation. 



1 Introduction 

The rewriting logic CRWL (Constructor-based conditional Re Writing Logic [9, 
10]) constitutes an approach to the integration of higher-order functional pro- 
gramming and logic programming, supporting non-deterministic lazy functions 
(with call-time choice semantics). Associated to CRWL, the authors also propose 
CLNC, a sound and complete lazy narrowing calculus, able to support sharing. 
Rather than a concrete operational model, CLNC is an abstract description of 
goal solving. 

Our aim is to define an experimental language and system that implements 
the CRWL paradigm. Such a language and system does already exist: TOy [16] 
and — the Prolog [5] implementation of — Curry [12] are Prolog implementations 
that support all aspects of CRWL programming, as well as some interesting 
extensions. Roughly, source programs are translated into Prolog code, and then 
the systems rely on the Prolog operational mechanism. Our implementation 
purposes are completely different. The development of our system is motivated by 
the implementation of an abstract machine for CLNC. The experimental aspect 
of the system is involved with being able to try out different implementation 
issues of functional logic languages. Hence, we are interested in an extensible 
and modifiable design of the system. 

* This work has been partially supported by the Spanish National Project T1C98- 
0445-C03-02 ‘TREND’. 

H. Kuchen and K. Ueda (Eds.): FLOPS 2001, LNCS 2024, pp. 216-232, 2001. 

© Springer- Verlag Berlin Heidelberg 2001 




An Abstract Machine Based System for a Lazy Narrowing Calculus 217 



Chakravarty and Lock summarize their research on the abstract machine 
based implementation of functional logic languages in [7]. They present the 
JUMP-machine, an abstract machine model “that integrates the execution mech- 
anisms underlying efhcient implementations of functional and logic programming 
languages.” Compared to the standard approach to abstract machines, the ma- 
chine code of the JUMP-machine, called JCode, is rather high-level (in the same 
way of STG, a very small functional language used as the abstract machine code 
for the Spineless Tagless G-machine in [18]). In essence, the abstraction level 
eases code generation and transformational code optimizations. 

The main ingredients used in our work are the lazy narrowing calculus CLNC 
and the JUMP-machine. Both have to be rehned in some sense. Regarding the 
calculus, some notion of strategy is needed in order to obtain an operational 
model. Regarding the JUMP-machine, it has to be adapted to the CRWL setting. 
For instance, we have to deal with non-deterministic functions, and hence with 
a non-deterministic version of strict equality. 

The rest of the paper runs as follows. In Sect. 2, we introduce the different 
languages used by the system: the source language, the intermediate language 
and the JUMP-machine language. In Sect. 3, we formally specify the opera- 
tional semantics of the intermediate language, along with the, informally stated, 
relation of each calculus rule to abstract machine code constructs. Section 4 is 
devoted to sketch out some implementation decisions, and conclusions are given 
in Sect. 5. 

2 Preliminaries 

The following process is accomplished by the system: GRWL programs are trans- 
formed into TFL programs, an intermediate language dehned to suit our inter- 
ests. Next, TFL programs are translated into — a modihed version of — JGode, 
the JUMP-machine code. The next subsections describe each language. 

2.1 CRWL Programs 

We use constructor-based signatures S = {DC,FS), where DC = UneiN-^^" 
and FS = UneiN-^'^" ranked sets of data constructors and defined func- 
tion symbols, respectively. Assuming a countable set DV ar of data variables, 
expressions e G Exp are dehned as follows: 

e ::= X (X E DV ar) \ h (hE DC LIES) \ (ei 62 ) (application) 

Two important subclasses of expressions are data terms t E Term, used to 
represent data values, and patterns p E Pat, a generalization of data terms. 
Patterns of the form f pi ... pm (/ E FS" ,m < n) are not data terms and can 
be used as an intensional representation of functions. They are dehned as: 

i ::= A (XEDVar) \ cti...t„ (c E DC") 

p ::= A [X E DV ar) \ c pi . . . pm (c E DC" , m < n) 

I f Pi ■■■ Pm (/ e FS", m <n) 
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A CRWL program is a set of well-typed^ defining rules for function symbols 
/. Each defining rule for / must have the following form: 

f Pi ■ ■ ■ Pn = <= 

left hand side (1) right hand side condition 

where I must be linear, pi must be patterns, e must be an expression such that 
var[e) C var[l)^ , and C must consist of hnitely many so-called joinability state- 
ments a == h, where a and h are expressions. Goals are syntactically identical 
to conditions. A joinability statement is similar to a strict equality, a pattern t 
is needed as a common value for a and h, but t is not required to be unique. 
Function-typed variables in goals or conditions that involve guessing a binding 
operationally, such as A 0 == Y, are not yet covered by the implementation. 
Neither termination nor confluence is imposed, and the latter allows us to cope 
with the dehnition of non-deterministic functions. 



Example 1. This CRWL program will be the basis of the next two examples. 



data nat = zero I sue nat 



— data type declaration 



coin = zero 
coin = sue zero 

zeros = [zero I zeros] 

take zero Ys = [] 

take (sue X) [] = [] 

take (sue X) [Y|Ys] = [Y I 



— non-deterministic 

— nullary function 

— infinite list 

— case distinction 

— in patterns 

X Ys] 



The hrst line introduces the user dehned data constructors zero/0 and smc/1. 
Next, the functions coin/0, zerosjl), and take/2 are dehned. Note that we use 
Prolog notation for lists, but this is just syntactic sugar, i.e., nil/Q and consj‘1 
are predehned constructors, instead of [ ]/0 and [.|.]/2. Thus, we are using the 
signature E = ({zero/0, nil suc/1, cons/^fi {coin/Q, zeros jQ, tafce/2}). 

We propose the goal take coin zeros == X, for which the expected answers 
are A = [ ] and A = [zero]. 



2.2 TFL Programs 

The source language is translated into a tiny functional logic (TFL) interme- 
diate language. TFL emerged as a way of abstracting from peculiarities of the 
source language. Hence, its use could help to consider different declarative source 
languages. Our hope is that TFL (or some extension of it) could be used to im- 
plement different computation models and extensions for CWRL. Up to now, 

^ For simplicity, we are not considering types in this paper. 

^ This is not a CRWL restriction, but a restriction of the current implementation. 
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we have implemented the demand driven strategy from [15], closely related to 
needed narrowing [3,4] and its non-deterministic extension [2]. The current syn- 
tax of TFL has been designed to express the definitional trees used in [2-4, 15]. 
Being CLNC an abstract description of goal solving, with the use of a concrete 
strategy we get a concrete operational model that enables the implementation 
of CRWL. 

A TFL program is a set of dehning rules for function symbols. The multiple 
CRWL dehning rules for a given function symbol / G FS" are transformed into 
a single TFL defining rule: 

f Xi ... Xn = te 

where Xi must be n new distinct variables and te must be a TFL expression. 
TFL expressions te G TExp are dehned as follows: 

te ::= case A of {alti | . . . | {X C DV ar) 

I when C then e (C* C TCond, e G Exp) 

I try {tei | . . . | te„} 

I e (e G Exp) 

alt ::= c Yi ... -> te (c G CS'^ , m <n, Y( DV ar) 

I fYi...Ym->te {feFS",m<n,YieDVar) 

Each case alternative is formed by a hat linear pattern (with new local variables) 
and an expression (the above variables can only occur within the expression). 
Each pattern has the same type that the case variable A. The alternatives of a 
case expression are exclusive: the symbols c or / must be pairwise different. 

Thus, TFL expressions make possible to explicitly express case distinctions, 
conditional expressions, non-deterministic choices, and CRWL expressions. For 
inductively sequential [3,4] CRWL source programs, the corresponding TFL pro- 
grams do not include the try construct. 

TFL conditions C G TCond are like CRWL ones, but those variables that 
have their hrst occurrence in the condition are explicitly represented by means 
of the extra construct. Regarding TFL goals, the extra part include all their 
variables. They are dehned as: 

C ::= extra Vi . . . Y„ in Cs (Vi E DV ar) 

I Cs 

Cs ::= ei == 62 (ei, 62 C Exp) 

I ei == 62 A Cs (ei , 62 e Exp) 

Example 2 . The CRWL program from Example 1 is translated into the following 
TFL program: 

coin = try {zero I sue zero} 



zeros 



cons zero zeros 
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take N L = case N of 

{ zero -> nil 
I sue N1 -> case L of 

{ nil -> nil 

I cons Y Ys -> cons Y (take N1 Ys)}} 

In addition, the proposed goal is transformed into the TFL goal: 

extra X in take coin zeros == X 

The use of an intermediate language is not new in the literature, neither in 
this area. TFL is quite similar to FlatCurry [13], an intermediate representation 
of Curry [12] programs, used by the Curry2Prolog compiler [5]. Albert et al. [1] 
use a “maximally simplihed abstract representation of programs” , also very close 
to TFL, for the specialization of functional logic languages. Their technique for 
partial evaluation, restricted to inductively sequential systems, could be directly 
applied in our system — to TFL programs without any occurrence of the try 
construct. 

2.3 JCode Programs 

JCode “resembles a block-structured, imperative language with a very restricted 
control and data flow, i.e., no explicit loops are possible (only recursion) and only 
single-assignment variables are allowed” [7]. Due to space restrictions, we do not 
detail the JCode syntax (neither the translations from CRWL to TFL, and from 
TFL to JCode). The most important JCode statements are assignments, SWITCH 
that implements case selection, CHOICES that realizes non-determinism, JUMP is 
used for tail calls, and JOIN for joinability (this statement was not part of the 
original JUMP-machine). There are also several return instructions that will be 
introduced later. 

Active objects. They are a central tool for the integration of functional and 
logic computations in the JUMP-machine framework. Active objects constitute a 
uniform object representation, which was hrst proposed for the Spineless Tagless 
G-machine [18], with the name of closures. Data objects are represented by a 
pointer to a method table and an environment (also called the active object 
arguments). In this presentation, the only provided method for active objects is 
their evaluation method (also called code). The different treatment of different 
objects is encapsulated in the code, avoiding the traditional use of tags. 

An active object is represented as 

((FUM mode as hs block), ws) 

where as is a list that contains the formal parameters, hs is a list that includes 
the free variables, that are not formal parameters, that appear within the code 
block (its evaluation method) . Finally, ws is a list that contains values for the 
variables in hs. Before executing the code in block, length{a,s) arguments are 
taken from the argument stack and bound to the elements of as. 
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Assignments. An assignment associates variables or function symbols to active 
objects, and has the following form: 

/ (or X) := FUN mode [Ai, . . . , A„] [Bi, . . . , Bm] block; 

It can be understood as a function dehnition: its name is / (or X), its n formal 
parameters are Ai, and its code is block. On execution, an assignment creates a 
new active object in the heap. Its heap reference is assigned to / (or X). The 
mode (UPD or NOUPD) indicates whether the object has to be updated with the 
result obtained after evaluating it the hrst time. 

A JCode program is a collection of assignments for function symbols. Each 
of them has the following form: 

/ := FUN NOUPD [Ai, . . . , A„] [ ] block; 

Apart from the assignments dehning function symbols, two other types of 
assignment are possible: for “external” and “internal” variables. An external 
variable is just one of the extra variables from goals or from rule conditions 
(explicitly represented in the TEL transformation). Assignments for external 
variables will always be like: 

A := FUN NOUPD [] [A] {RET LVAR A} 

They are needed to ensure that these variables will be created in the heap before 
using them. Internal variables^ are new variables generated during the compila- 
tion process to JCode. They are needed because JCode does not support nested 
expressions. An internal variable assignment is of the following form: 

#i := FUN mode [ ] [B\, . . . , 5„] block 

Internal variables can give rise to updatable active objects {mode is set to UPD 
instead of NOUPD). They permit to implement sharing and laziness, by ensuring 
that an updatable active object is evaluated at most once (updating the active 
object with the result of the evaluation). 



Abstract machine architecture. A state of the non-optimized JUMP-ma- 
chine comprises nine components: 

— The code component specihes the next operation to be executed. 

— The argument stack stores the currently supplied arguments. 

— The return stack keeps track of what remains to be done after performing a 
sub-computation. 

— The update stack is used to update an updatable active object with the 
obtained result after executing its code for the hrst time. 

— The choice point stack helps to manage the search through alternative com- 
putations. 

^ They are noted as #i, where i is just a counter. 
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— The trail records the updates of suspensions and variable bindings, in order 
to be able to undo them on backtracking. 

— The heap is a collection of active objects. 

— The global environment is a mapping of function symbols, and goal variables, 
to the references denoting the associated active objects in the heap. 

— The joinability stack is used to solve joinabilities, and was not present in the 
original JUMP-machine. 

The initial state of the machine stores the goal code block in the code com- 
ponent, the active objects for goal variables and dehned function symbols are 
put into the heap, and their references are stored in the global environment. 
Everything else is initially empty. 

Example 3. The TEL program from Example 2 is translated into the following 
JCode program: 

coin := FUN NOUPD [] [] 

{CHOICES 

{RET TERM zero []} 

I I 

{#6 := FUN NOUPD [] [] {RET TERM zero []}; 

RET TERM sue [#6] } 

} 

Remember that nested expressions are not allowed in JCode. Eor instance, in 
sue zero, zero is a nested expression, and thus it has to be translated to an 
internal variable assignment. 

zeros := FUN NOUPD [] [] 

{#4 := FUN UPD [] [] {JUMP zeros []}; 

#5 := FUN NOUPD [] [] {RET TERM zero []}; 

RET TERM cons [#5, #4]} 

The same happens with cons zero zeros. The difference with respect to the 
previous function dehnition is that one of the nested expressions is a function 
call; the code block reflects this fact by using a JUMP statement. 

take := FUN NOUPD [N, L] [] 

{SNITCH N OF 

TERM zero [] : {RET TERM nil []} 

TERM sue [Ml] : 

{SNITCH L OF 

TERM nil [] : {RET TERM nil []} 

TERM cons [Y, Ys] : 

{#0 := FUM UPD [] [Ml, Ys] 

{#1 := FUM UPD [] [Ys] {JUMP Ys []}; 

#2 := FUM UPD [] [Ml] {JUMP Ml []}; 

JUMP take [#2, #1]} 
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#3 := FUN UPD [] [Y] {JUMP Y []}; 

RET TERM cons [#3, #0]} 

} 

} 

The machine initial state includes the goal code block in its code component. 

{#7 := FUN UPD [] [X] {JUMP X []}; 

#8 := FUN UPD [] [] 

{#9 := FUN UPD [] [] {JUMP zeros []}; 

#10 := FUN UPD [] [] {JUMP coin []}; 

JUMP take [#10, #9]}; 

JOIN #7 #8; 

RET } 

Goal variables (like df in this example) and dehned function symbols are explic- 
itly represented in the heap, before execution begins. 

3 TFL Operational Semantics 

Along this section, we will present a calculus that formally specihes the TFL 
operational semantics. Our aim for dehning the calculus was to show the JCode 
operational behavior in a simpler context. The machine is intended to explore 
all the possible computations, while the calculus is intended to perform a sin- 
gle computation. Along the calculus presentation, we will — rather informally — 
state the relation of the JCode constructs behavior with the different rules. 

Notation, definitions, and assnmptions. The calculus manages configura- 
tions [E , C, (t) (or {E, e, cr)), where E is an environment where we store vari- 
able bindings, G is a TFL goal (or a TFL condition) to be solved (or e G TExp 
is an expression to be evaluated to head normal form), and cr is the computed 
substitution. We assume that for every conhguration, the substitution has been 
applied to the other components: 

— Ca = C (or ea = e) 

— Ea = E, where Ea = {X i — ea for all A i— e G E} 

We also assume that the computed substitutions are idempotent: the rules that 
involve a modihcation on the substitution replace a variable by a pattern that 
does not include any occurrence of the substituted variable. Hence, applying 
again the same substitution has no effect. 

It’s worth noting that a variable, say X, that occurs in an environment 
E, say A i-P- e ^ E, is always a fresh variable, that comes from a function rule 
application (renaming with fresh variables is required) . Such a variable can act as 
a parameter or as a pattern local variable in a function rule. Hence, environments 
do not contain extra variables (except as bindings for an environment variable). 

The notation (HME^ e) is used to indicate that an expression e G TExp is in 
head normal form with respect to an environment E, i.e.. 
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— e = c Cm (c G CS", m <n), or 

— e = / ^ (fe FS’^, m < n) , or 

— e = X if X does not have a binding in E. 

Roughly, head normal forms are expressions with the outermost appearance of 
a pattern. 

We also use the notation e 'EX to abbreviate e ei . . . e^. 



Goal solving ^-soive- The initial configuration (0, C, id) starts with the 

empty environment, the TFL goal C to be solved, and the identity substitution. 
If the goal is solvable, we will be able to apply different rules until we reach 
a final configuration (E, true, cr). By restricting the computed substitution to 
the goal variables, we get the answer substitution. This process is guided by the 
SOLVE rule, which simply states that a goal is solved like a condition: 

(0, C, id) — [E, true, cr) 

[solve] 

(0, C, id) — ^soive {E, true, a) 

The machine initial state stores the goal code in its code component. The exe- 
cution begins with this code until a success hnal state is reached (if any). 



Condition solving >c- The presence of extra variables in a condition is 

ignored in the calculus conhguration. Note that there is no name conflicts due 
to the use of rule variants, and to the fact that when we have a choice, only one 
of the alternatives is selected'^ . 

(E, C, cr) — (E', true, cr') 

[ex] 

(if, extra in C, cr) — [E' , true, cr') 
Notwithstanding, in the machine side, we need JCode statements of the form 

Xi := FUN NOUPD [] [W] {RET LVAR Xi} 

to ensure that these variables will be created in the heap before using them. 

Up to now, we deal with conjunctions of joinability conditions by solving 
them sequentially. 



[E, Cl == 62 , cr) — (E', true, cr') (E', Ccr', cr') — (E", true, cr") 
[and] 

[E, Cl == 62 AC, cr) — [E", true, a") 

^ A calculus intended to explore all the possible computations, should not ignore extra 
variables. 
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The translation process of TFL to JCode ensures this sequential behavior. When 
a joinability condition is solved, the success is indicated by a special return 
statement RET. If something remains to be done (the return stack will not be 
empty), the machine proceeds with the execution. 

A joinability condition is solved by computing the head normal form of both 
sides, and then solving a joinability condition between head normal forms. 

(A, ei, a) — ^hnf [E' , ej, a') (£", e^a-' , a') — ^hnf [E" , e(,, cr") 

{E", (ej,7") == e' 2 , a") {E'", true, ,7'") 

[eq] 

{E, ei == 62, cr) — {E'”, true, cr'") 

The JOIN statement performs the head normal form computations, stores the 
results in the heap, and proceed to compare them, as will be explained later. 

Head normal forms ^-hnf- In some of the previous rules, TFL expressions 

need to be evaluated to head normal form. Expressions are evaluated gradually 
until a head normal form is obtained. The rules that accomplish this task are 
the following ones: 

{E, 6 , , 7 ) {E', e', a'} {E' , e' , a') ^hnf {E" , e" , a") 

[no-hnf] 

(A, 6, cr) — ^hnf [E” , e" , a") 

if not (HNFb e). 

[hnf] [E, 6 , cr) — ^hnf [E, 6 , cr) if (HNF_e e). 

When the machine returns a value, it always corresponds to a head normal 
form evaluation. At this point, the code component of the state will keep a 
return statement: RET LVAR X, RET TERM c as, RET PARC c as or RET PAPF f 
as, corresponding to a variable, a data term or a partial application. 

TFL expressions Those TFL expressions that are not in head normal 

form are handled by the following rules that help to obtain head normal forms. 

— This rule allows the non-deterministic selection of a TFL expression e,- from 
the rest of them. 

[try] (A, try {. . . | e,- | . . . } o^, cr) — ^ (A, e,- W, cr) 

Up to now, the machine implements this kind of non-determinism by the use 
of rule choice points (similar to the WAM [19] choice points) that sequentially 
select the code blocks, storing the remaining alternatives in the choice point 
stack. This roughly corresponds to the execution of a statement: 



CHOICES {. . . II blocki || . . . }; 

where blocki would be the translation to JCode of the TFL expression e,-. 
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— Conditional expressions require solving the condition, and only in case of 
success to proceed with the guarded expression. 

[E, C, cr) — (E', true, cr') 

[when] 

{E, when C then e cTk, cr) — > (E', (e 'Ok)cr' , cr') 

The translation to JCode ensures this behavior. After returning from the 
condition solving process, the return stack will store a return continuation 
with the needed information to proceed with the execution by evaluating the 
expression. 

— The variable on which a case distinction is performed has to be evaluated 
to head normal form. It’s worth noting that we are able to ensure that any 
variable that appears within a case is always bound to some expression in the 
environment. Hence, the binding expression has to be evaluated. If the ob- 
tained head normal form is a non- variable pattern, say h e\ . . . e„, at most 
one of the case alternative guard patterns, say h X\ ... A„, will match 
the result. In this case, pattern matching is performed: the Xi variables are 
bound to the e,- expressions and stored in the environment, and the alterna- 
tive guarded expression e' is selected. We call this situation a deterministic 
case application. 

[E, X, cr) — ^hnf [E' , h cr') 

[case] 

(E, case A of {. . . h X„ — t e' . . . } oT, cr) 

— t [E' U {X„ ^ ^}, (e' W)o-', cr') 

The obtained head normal form can also be a variable Y (this means that 
there is no binding for Y in the environment E'). This situation will lead 
to a non-deterministic case application, in the sense that a variable unihes 
with each alternative pattern. Thus, any of the alternative expressions may 
be non-deterministically selected. 

(E, X, a) ^hnf (E', Y, a') 

[nd-case] 

(E, case A of {. . . h X„ — t e' . . . } oT, cr) 

— t ((£" U {A„ 1 -^ Tn})cro, (e' W)o-'o, cr' ■ {Y \ h Y„}) 




where Y„ are fresh variables. 

Case selection is performed by the JCode statement 

SWITCH A OF alts; 

It puts the code of the alternatives alts into the return stack, and “calls” A, 
by means of a JUMP statement, that will get the active object for A. Depend- 
ing on the kind of active object, it executes its evaluation method (for the 
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first time) or it gets a previously computed result. The return continuation 
put by a SWITCH instruction into the return stack stores all the relevant in- 
formation to continue, depending on the kind of head normal form returned 
by the sub-computation. 

If a non- variable is returned, the matching alternative is selected. If a logical 
variable is returned, a variable choice point is created on top of the choice 
point stack. Its task is to sequentially generate all possible bindings for the 
variable according to the patterns of the SWITCH. 

In the case of inductively sequential programs, choice points are only built in 
order to manage the different bindings of a variable, leading to an on-the-fly 
detection of deterministic computations. 

— The function call rule performs parameter passing binding the arguments e,- 
to the formal parameters Xi in the environment, without evaluating them. 
The function dehnition right hand side substitutes the function call. 

[app-fun] {E, feXW, cr) — > {E U {X„ c^eX}, raE, a) 

where (/ X„ = r) is a renaming of the TFL 
program rule for / with fresh variables. 

The translation process to JCode ensures that the arguments are processed 
before the call to the function. They are just allocated into the heap, without 
evaluating them, and their heap addresses are put onto the argument stack. 
When the function call is performed by means of a JUMP statement, the 
evaluation method for / is executed. 

— A variable needs evaluation (i.e., is not in head normal form) when it has an 
associated binding in the environment. For instance, a variable that repre- 
sents a formal parameter could be evaluated (only if necessary). When this 
is the case, the environment binding expression should be evaluated to head 
normal form. We remember that computed substitutions are always applied 
to environments: this fact ensures sharing and that evaluation is done at 
most once. 

{E, e, a) — ^hnf {E' , e' , a') 

[var] 

{E D {X e}, X oT, cr) 

— 7> ((if'\{A i-q> err'}) U {X i-q> e'}, e' aE <r' , <r') 

As mentioned above, this is performed by a JUMP statement. 

Note that we are not considering variable applications because they are not 
yet handled by the system. 

Condition solving between head normal forms TFL and JCode 

joinability deal with head normal forms to guarantee laziness: as soon as a mis- 
match is detected, the whole process fails. 

The following rules (decomposition, imitation, binding, variable binding, and 
identity) control condition solving between expressions in head normal form, say 
Cl and 62. Their obvious symmetrical counterparts are omitted. 
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[dec] 



(E, ai == &i A ... A a™ == bm, cr) — {E' , true, cr') 



[E, h am == hhm, cr) — {E', true, cr') 



[iMl] 



{Eax, Ym 



crx 



bmO-x, (T ■ {X \ h Ym}) — tc [E' , true, a') 



[E, X ==h bm, cr) — [E', true, cr') 



if does not occur in h bm at any position outside the scope of 
evaluable function calls. Ym are fresh variables. 



[bd] 
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== h, cr) - 


-Aj {Edh, true, cr • 






[vbd] 


[E, X 


== Y, cr) - 


— tj {Eax, true, cr 


<7h 

•{£^) 


if A 7^ Y 


[id] 


[E, X 


== -t) - 


-Aj {E, true, cr) 







One of the tasks of the JOIN statement is to lazily compare for joinability the 
two expressions it has previously reduced to head normal form. This means that 
only special types of active objects are to be compared: those that represent 
head normal forms, i.e., RET LVAR X, RET TERM c as, RET PARC c as and RET 
PAPE f as. 



Failure rules. If none of the rules can be applied, the computation fails. As 
usual in non-deterministic settings, we consider that the overall goal solving 
process fails if all the possible computations fail. 

The machine implementation incorporates explicit fail situations, in order 
to fail as soon as possible. In this case, if alternative computations remain to 
be explored, backtracking is automatically performed. After a successful goal 
solving process, asking for more solutions would also lead to backtrack. When 
the choice point stack is empty, the machine execution stops indicating that the 
last attempt to solve the goal has failed. 

4 Implementation Outline 

Due to our interest on experimenting with different computation models, as well 
as the corresponding compilation schemes for TFL programs, extensibility and 
modihability were major concerns for the implementation. This led us to the 
selection of an object-oriented approach and the use of design patterns (e.g., [8]) 
for the system design and implementation. In particular, we are using Java, which 
is available on a wide range of platforms. We have a running implementation 
extended with a graphical user interface, that is depicted in Fig. 1. Apart from 
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Fig. 1. System graphical user interface 



the CRWL source program, the user can see different translations performed by 
the system while compiling to JCode: the source program with type annotations 
(after performing type inference), the TFL resulting program and the JCode 
program. 

The Java language portability leads, at present, to an interpreted virtual ma- 
chine that handicaps performance. Furthermore, we have not considered any kind 
of optimization: neither dedicated optimizations to the generated JCode, nor the 
details on how to obtain an efficient implementation of the JUMP-machine given 
in [7], nor performance considerations of the different Java constructs. Hence it 
is evident that we are far from other more mature abstract machine based imple- 
mentations, even developed in Java such as the Curry2Java implementation [14], 
and even further from the Munster Curry implementation by Lux and Kuchen 
[17], that compiles into native machine code using the well-known “C as portable 
assembler technique” . 

Our design heavily relies on the Visitor pattern. Each visitor represents an 
operation to be performed on the elements of an object structure (in our case, the 
program representation in the different languages). Visitor lets us define opera- 
tions without changing the classes of the elements on which it operates. This way, 
the classes that implement program structures remain untouched when different 
processing strategies are applied. For instance. Fig. 2 shows the class diagrams 
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Fig. 2. Types representation and types visitors class diagrams 



for the representation of types and (part of) the different visitors operating on 
them. 

Just by switching the strategy visitor that operates on the type annotated 
internal source program representation, we can consider a very simple alternative 
computation model. Standard lazy functional languages use textual order rule 
selection and left to right pattern matching. Although such a naive strategy is 
clearly worse than the implemented one, it makes sense to consider it in the 
context of functional logic languages. 

The only change to our setting is to follow a different translation from CRWL 
source programs to TFL. A straightforward approach is to translate a CRWL 
function dehnition, composed by m rules, into a single TFL rule whose right hand 
side is a try expression (if m > 1), with m case expressions inside, corresponding 
to the rules individual translations (if, for a concrete rule, the left-hand side 
patterns were variables, no case expression is obtained). A clear disadvantage 
of the above simple translation is that for CRWL functions with at least two 
rules, a choice point would always be generated, even for non-overlapping left- 
hand sides. Taking into account this observation, one could conceive a better 
translation, as illustrated in the following example. 

Example Consider the CRWL program 

fl2 = l gl = 0 

f2X = 2 g2 = 3 

f 1 2 = 3 

Taking into account overlapping, we get this translation to TFL: 
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g XI = case XI of { 1 -> 0 I 2 -> 3 } 

f XI X2 = try { case XI of { 1 -> case X2 of { 2 ->1 } } 

I case XI of { 

2 -> 2 

I 1 -> case X2 of { 2 -> 3 } } } 

Opposed to this ideal situation, that would enable to offer two alternative lazy 
narrowing strategies, considering more interesting computation models would 
obviously involve more substantial changes. Our hope is that the current system 
design will ease the modihcations. 

5 Conclusions and Future Work 

We have dehned an intermediate language that allows us to implement CRWL 
programs [9, 10] using a demand driven lazy narrowing strategy [15]. A calculus 
that formally specihes the operational semantics of this intermediate language 
has also been dehned. We have adapted the JUMP-machine to the CRWL frame- 
work, taking into account non-deterministic functions and joinability statements. 
Completeness of CLNC is not realized by our current implementation. This could 
be mended by adopting some fair search strategy. 

Although we have a running implementation, the current state of the system 
is far from being over. Besides all the optimizations that should be performed, we 
are mainly interested in extending the system to implement different computa- 
tion models and extensions of the CRWL framework. Regarding the computation 
models, we plan to consider simplihcation, residuation, and dynamic type check- 
ing that has been proposed in [11] for higher-order narrowing computations in 
the CRWL framework, and suggested in [6] for a polymorphic setting. The lat- 
ter will enable us to accept any kind of function-typed variables in conditions 
and goals. We are also considering different CRWL extensions, such as algebraic 
datatypes, type classes, constraints, and a declarative debugger. 

Another interesting line of future work is to formalize the relationship be- 
tween TFL and JCode, which would help to prove the soundness of the imple- 
mentation. 
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Abstract. In this work, we consider the extension of the Inductive Func- 
tional Logic Programming (lELP) framework in order to learn functions 
in an incremental way. In general, incremental learning is necessary when 
the number of examples Is infinite, very large or presented one by one. 
We have performed this extension in the FLIP system, an implementation 
of the IFLP framework. Several examples of programs which have been 
induced indicate that our extension pays off in practice. An experimental 
study of some parameters which affect this efficiency is performed and 
some applications for programming practice are illustrated, especially 
small classification problems and data-mining of semi-structured data. 

Keywords: Inductive functional logic programming (IFLP), inductive 
logic programming (ILP), incremental learning, theory revision. 



1 Introduction 

Since the beginning of the last decade. Inductive Logic Programming (ILP) [14] 
has been a very important area of research as an appropriate framework for the 
inductive inference of first-order clausal theories from facts. As a machine learn- 
ing paradigm, the general aim of ILP is to develop tools, theories and techniques 
to induce hypotheses from examples and background knowledge. ILP inherits the 
representational formalism, the semantical orientation and the well-established 
techniques of logic programming. The ILP learning task can be defined as the 
inference process of a theory (a logic program) P from facts (in general, positive 
and negative evidence) using a background knowledge theory B (another logic 
program). More formally, a program P is a solution to the ILP problem if it 
covers all positive examples (P U P |= E'^) and does not cover any negative 
examples {B\J P E~). 

ILP has provided an outstanding advantage in the inductive machine learn- 
ing field by increasing the applicability of learning systems to theories with more 
expressive power than propositional frameworks. Functional logic languages fully 
exploit the facilities of logic programming in a general sense: functions, predi- 
cates and equality. The inductive functional logic approach (IFLP) [9] is inspired 
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by the idea of bringing these facilities to the mainstream of ILP [13]. From a 
representational point of view, IFLP is at least as suitable for many applications 
as ILP, since FLP programs subsume LP programs. Moreover, many problems 
can be stated in a more natural way by using a function than a predicate. For 
instance, classification problems are solved in ILP by using predicate symbols 
such that one of their arguments represents the class. 

A learning system is incremental if the examples are supplied one (or a few) at 
a time and after each one the system induces, maintains or revises a hypothesis. 
This operation mode is opposite to that of non-incremental systems (known 
as batch systems) for which the whole evidence is given initially and does not 
change afterwards. 

Incrementality in machine learning is a powerful and useful technique that 
tends to improve performance by reducing the use of resources. In regard to 
spatial resources, many problems can consist of a large evidence, which cannot 
fit in memory, and an incremental handling of this evidence is a straightforward 
and convenient solution (there are, of course, other solutions, such as sampling 
or caching). Secondly, there is also a temporal resources improvement, since in- 
duction is much more computationally expensive than deduction. Incrementality 
allows the establishment of a hypothesis in the early stages of the learning pro- 
cess. If this hypothesis is stable, the next work will be deductive in order to check 
that the following evidence is consistent with the current hypothesis. Moreover, 
there are other reasons for using an incremental learning approach[2j: it may be 
impossible to have all examples initially or even its number cannot be known. 
In this sense, incrementality is essential when the number of examples is infinite 
or very large. This is the case of knowledge discovery from databases [6]. 

Incrementality has been studied by the ILP community. Some incremental 
ILP systems are CLINT [17], MOBAL [12], FORTE [19] and CIGOL [15]. On 
the other hand, predicates which are already known (learned) can be used as 
background knowledge in learning new predicates, and so on. This allows the 
learning of programs which define more than one concept at the same time in a 
way that is also incremental [18]. 

In this paper we present an incremental algorithm for the induction of func- 
tional logic programs. Starting with the IFLP general framework defined in [8], 
we focus on the case of learning one target concept from an evidence whose ex- 
amples are given one by one. The IFLP framework has been implemented as the 
FLIP system [5]. We extend its main algorithm in order to make it incremental. 

The paper is organised as follows. In Section 2, we review the IFLP frame- 
work and the FLIP system. Section 3 defines an incremental IFLP algorithm 
and extends the FLIP system according to this improvement. From this point, 
the system can operate not only as an incremental or non-incremental theory 
inducer but as a theory evaluator/reviser if one or more initial theories are pro- 
vided. Some results and running examples are presented in Section 4. Finally, 
Section 5 concludes the paper and discusses future work. 
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2 IFLP Framework 

IFLP can be defined as the fnnctional (or equational) extension of ILP^. The 
goal is the inference of a theory (a functional logic program^ P) from evidence (a 
set of positive and optionally negative equations E). The (positive and negative) 
examples are expressed as pairs of ground terms or ground equations whose right 
hand sides are in normal form wrt. B and P. Positive examples represent pairs 
of terms that will have to be proven equal using the induced program, whereas 
negative examples consist of pairs of terms, where the Ihs term has a normal form 
different from the rhs term. In this section we briefly review the IFLP framework 
and its implementation. More complete descriptions of the framework and the 
system can be found in [8] [9] [5] . 

The IFLP framework is based on a bottom-up iterative search which gener- 
alises the positive examples. The generalisation process is limited by a number 
of restrictions that eliminate many rules that would be inconsistent with old and 
new examples or useless for the induction process. We name this limited gener- 
alisation Consistent Restricted Generalisation (CRG). More specihcally, a CRG 
of an equation e is dehned as a new equation e' which is a generalisation of e (i.e. 
there exists a substitntion a such that e'er = e), and there are no fresh variables 
on the rhs of e' and e' is consistent wrt. the positive and negative evidence. 

The basic IFLP algorithm works with an initial set of equations (we denote 
EH^ Equations Hypothesis) and a set of programs {PH^ Program Hypothesis) 
composed exclusively of equations of EH. The new generalised equations ob- 
tained from a first stage are added to EH (removing duplicates) and new unary 
programs from each equation are generated, which are added to PH (removing 
duplicates). From this new set PH, the main loop of the algorithm selects hrst 
a pair of programs according to the selection criterion (currently, the pair which 
covers more positive examples with the minimum length of the rules) and then 
combines them. 

Two operators for the combination of rules of each pair of programs have 
been developed: a Union Operator, whose use is restricted in order to avoid 
non-coherent solutions, and an Inverse Narrowing operator, which is able to 
introduce recursion in the programs to be induced. The union operator just 
gives the program resulting from the union of other two programs. The inverse 
narrowing, on the contrary, is more sophisticated. This operator is inspired by 
Muggleton’s inverse resolution operator [13]. An inverse narrowing step has as 
input a pair of equations: the receiver equation Cr and the sender equation e^. In 
an informal way, the sender rule is reversed and a narrowing step is performed 

^ It is obvious that any problem expressed in the ILP framework can also be expressed 
in the IFLP framework, because all the positive facts el of an ILP problem can be 
converted into equations of the form el = true and all the negative facts e~ can be 
expressed as e~ = false. 

^ A functional logic program is a logic program augmented with a Horn equational the- 
ory. The operational semantics most widely accepted for functional logic languages 
is based on the narrowing mechanism [7]. 
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to each of the occurrences of the rhs of the receiver rule. In this way, there are 
as many resulting terms as occurrences to which the sender rule can be applied. 
Each of these terms are used as rhs of new rules whose Ihs’s are the Ihs’s of 
the receiver rule. These rules are the output of the inverse narrowing step. For 
instance, consider : X + s(0) = s(X) and : X + 0 — X. Reversely using the 
sender equation in two different occurrences of the rhs of the receiver equation 
we can construct two different terms: s(X + 0) and s{X) + 0. The resulting 
equations are X + s(0) = s(X + 0) and X + s(0) = s{X) + 0. This mechanism 
allows the generation of new programs starting with two different rules. The new 
rules and programs produced by the application of inverse narrowing are added 
to the set of rules and programs EH and PH. 

The loop finishes when the stop criterion (StopCrit) becomes true, usually 
when a desired value of optimality has been obtained for the best solution or 
a maximum number of loops has taken place. In the first case, one or more 
solutions to the induction problem can be found in a rated PH. In the latter 
case, partial solutions can be found in PH. 

For the induction of programs using background knowledge we use the fol- 
lowing method. It permits the introduction of function symbols from background 
knowledge into the program that is being induced. Briefly, the method consists 
of applying the inverse narrowing operator with a rule from the background 
theory. In this way it is possible to obtain new equations with the background 
function in their rhs. For instance, if the background theory B contains the equa- 
tion sum{X, 0) = X, then the equation prod{X, 0) = 0 can be used to generate 
prod{X, 0) = sum{0, 0) by the application of inverse narrowing. In this way, 
we have introduced a function from the background theory into the induction 
process. 



2.1 The FLIP system. 

To implement this algorithm we have built the FLIP system. FLIP is a project 
built in C, that implements the Inductive Functional Logic Programming frame- 
work. The system includes an interface, a simple parser, a narrowing solver, an 
inverse narrowing method, and a CRG generator (see [5] for details). 

We have tested our system with several examples of different kinds. FLIP 
usually hnds the solution after a few loops, but, logically, this depends mainly 
on the number of rules of the solution program and on the ‘quality’ of the 
initial examples. The length of the induced program is not limited. However, 
each new rule requires at least one iteration of the main loop. Consequently, 
FLIP deals better with shorter hypotheses. The main interest (and complexity) 
appears when learning recursive functions. In this sense, some relevant recursive 
functional logic programs induced without the use of background knowledge can 
be seen in Table 1. 

Functions such as app are more naturally defined as a function than as a 
predicate. No mode information is then necessary. It should be highlighted that 
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Induced program 


Description 


Steps 


sum(s(X),Y) = s(sum(X,Y)) 
sum(0,Y)=Y 


Sum of two natural numbers 


1 


length(-(X,Y)) = s(length(X)) 
length(A)=0 


Length of a list 


2 


consec(-(X,Y)) = consec(X) 
consec(-(-(X,Y),Y)) = true 


Returns true if there exist 
two consecutive elements 
in a list 


1 


drop(0,X) = X 

drop(s(X),-(Y,Z)) = drop(X,Y) 


Drops the N last elements 
of a list 


1 


app(-(X,Y),Z) = -(app(X,Z),Y) 
app(A,X) = X 


Appends two lists 


1 


member(-(X,Y),Z) = member(X,Z) 
member(-(X,Y),Y) = true 


Returns true if Z is in 
a list 


1 


last(-(X,Y)) = last(X) 
last(-(A,X)) = X 


Last element of a list 


1 


geq(s(X),s(Y)) = geq(X,Y) 
geq(X,0) = true 


Returns true if the first 
element is equal or greater 
than the second 


1 


sum(s(X),Y) = s(sum(X,Y)) 
sum(0,Y)=Y 

prod(s(X0),Xl) = sum(prod(XO,Xl),Xl) 
prod(0,X0) = 0 


Addition and Multiplication 
at the same time 


3 


mod3(0) = 0 
mod3(s(0)) = s(mod3(0)) 
mod3(s(s(0))) = s(s(mod3(0))) 
mod3(s(s(s(X0)))) = mod3(X0) 


The mod 3 operation 


3 


even(s(s(X)) = even(X) 
even(O) = true 


Returns true if natural 
number is even 


1 



Table 1. Recursive programs induced without background knowledge® 



the FLIP system is not restricted to learn one function at a time, as can be shown 
for the sum^cprod functions, which are induced together from a mixed evidence. 

Finally, with the use of background knowledge, more complex problems can 
be generated, as is illustrated in Table 2. 

The results presented in this section were obtained by randomly selected ex- 
amples. Evidence was relatively small in all cases: from 3 to 12 positive examples 
and from 2 to 11 negative examples. For a more extensive account of results, 
examples used, etc. please visit [4] . 



® The constructor symbols s, • and A represent the successor, insert and the empty list 
function symbols, respectively. 
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Induced program 


Description 


Bkg. 


Steps 


rev(-(X0,Xl)) = app(rev(XO),-(A,Xl)) 
rev(A) = A 


Reversal of a list 


append 


2 


suml(-(X0,Xl)) = sum(suml(XO),Xl) 
suml(-(A,X0)) = XO 


Sum of a list of 
natural numbers 


sum 


1 


maxl(-(X0,Xl)) = max(Xl,maxl(XO)) 
maxl(-(A,X0)) = XO 


Max of a list of 
natural numbers 


max 


1 


prod(s(X0),Xl) = sum(prod(XO,Xl),Xl) 
prod(0,X0) = 0 


Product of two 
natural numbers 


sum 


1 


fact(s(X0)) = prod(fact(X0),s(X0)) 
fact(O) = s(0) 


Product of two 
natural numbers 


prod 

sum 


4 


sort(-(X0,Xl)) = inssort(Xl,sort(XO)) 
sort (A) = A 


Inefficient sort 
of a list 


inssort, 
gt, if 


1 



Table 2. Some programs induced with background knowledge 



3 Incrementality in IFLP 

In this section we present an extension of the IFLP algorithm in order to make 
it incremental. 

Given the current best hypothesis P selected by the algorithm, three possible 
situations can now arise each time that a new positive example e is presented: 

Definition 1. HIT. e is correctly covered by P, i.e., P \= e. 

Definition 2. NOVELTY. Given the old evidence OE, a novelty situation is 
given when e is not covered by P but consistent, i.e., P^eAVdG OE : 
P U {e} \= e! . 

Definition 3. ANOMALY, e is inconsistent with P i.e., P ^ ~^e. 

Both novelty and anomaly situations will require the revision of the current best 
hypothesis in order to match the new examples. In the first case, the theory must 
be generalised in order to cover the new evidence, whereas in the other case, it 
must be specialised in order to eliminate the inconsistency. Hence, the topic 
known as theory refinement [21, 22] is a central operation for incremental learn- 
ing. The incremental reading of negative examples can also be contemplated, 
but in this case only hits and anomalies are possible. 

As has been commented in the introduction, incremental learning forces the 
introduction of a revision process. Let us denote by CoreAlgorithm the algo- 
rithm which induced a solution problem from an old and new positive (and 
negative) evidence and a background knowledge given an initial set of hypothe- 
ses and an initial set of theories (programs). The calling specification of the 
algorithm is: 

CoreAlgorithm (OE+ , OE~ , NE'^ , NE~ , B, EH, PH, StopCrit) 

This algorithm generates the CRGs from the new positive evidence (although 
consistency is checked wrt. both old and new evidence: OE~^,OE~,NE^ and 
NE~). 
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The algorithm starts with the initial sets EH and PH which can be both 
empty. The first process is the generalisation of the new positive evidence NE~^. 
The old positive evidence OE'^ is only used for checking consistence of these 
generalisations, as well as the old and new negative evidence OE~ and NE~. 
When learning non-incrementally, OE~^ and OE~ are usually empty. The result 
of the CRGs is added then to EH (removing duplicates) and generates unary 
programs which are added to PH. Then, the algorithm enters a loop which has 
been described in the previous section until a program in PH covers both OE~^ 
and NE~^ (and consistent with old and new negative evidence) with a certain 
optimality value given in the StopCrit. 

In any incremental framework the number of examples that should be read in 
each iteration must be specified. The most flexible approach is the use of adapt- 
able values, which can be adjusted by the use of heuristics. The simplest case, 
on the contrary, is the use of a constant value, which is usually 1. In our case, we 
have adopted an intermediate but still simple approach. We use an initial incre- 
mentality value {start-up value) which is different from the next incrementality 
value. The reason for different initial incrementality values is the CRG stage, 
which may require greater start-up values than the next incrementality value, 
which is usually 1. 

According to the previous rationale, new additional parameters are required 
in our algorithm: is the initial positive incrementality value {start-up value), 

which determines how many positive examples are read initially, ig is the initial 
negative incrementality value. is the positive incrementality value and i~ is the 
negative incrementality value, which determine how many positive and negative 
examples are read at each incremental step. With these four parameters, the 
overall algorithm can be generalised as follows: 

OverallAlgorithm(R'^, E~ , B, PH, StopCrit, Optimality Cr it, ig ,ig , P ,i~ ,no^rev) 

begin 

OE'^ := 0, OE~ := 0 // old examples 
IE~^ := 0, IE~ ■.= % I j ignored examples 
EH := Extract AllEquationsFrom(PH) 

PH := PH U {EH} // adds equations from EH as unary programs 
NE^ := Remove(&£'''", io") // extracts the first elements from E'^ 

NE~ := Remove(&E“, id") // extracts the first i}} elements from E~ 
CoreAlgorithm(OE+ ,OE~, NE+ ,NE~,B, &iEH, k,PH, StopCrit) 
while {E~^ 7 ^ 0) or {E~ ^ 0) do 
BestSolution:= SelectBest(PR, OptimalityCrit) 

NE^ := Remove(&E''', i”*") // extracts the first P elements from E"*" 

NE~ := Remove(&E“, i“) // extracts the first i~ elements from E~ 
if Bestsolution \= NEP and Bestsolution p NE~ then / / Hit 
lE^ := lE'^ U NE~^ // the new -|- and - examples are ignored 
IE~ := IE~ U NE~ // and the Best Solution is maintained 
else / / Novelty or Anomaly. The sets are revised 

RecomputeCoverings(&ER, &iPH, lE'^ , IE~ , NE~^ , NE~) 
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// recomputes the coverings of equations and programs wrt. 

// the new examples and (optionally) the ignored examples 
{ NE~^ := lE^ U NE^ } j j Option. Ignored + examples are reconsidered 
{ NE~ ;= IE~ U ~NE~ } j j Option. Ignored - examples are reconsidered 
BestSolution:= SelectBest(PFI, OptimalityCrit) 
if not (Bestsolution \= NE^ and Bestsolution ^ NE~) then 
if not no-rev then 

CoreAlgorithm(0£'+ , OE~ , NE + , NE ~ , B, &iEH, kPH, StopCrit) 

endif 

OE~^ OE'^ U NE^\ / / the new -|- examples are now added to old 

OE~ := OE~ U NE~ ■, / / the new - examples are now added to old 

endwhile 

return BestSolution:= SelectBest(PFf, OptimalityCrit) 

end 

Plainly, the algorithm considers two cases (if-else). The hrst one is given when 
the best solution covers and is consistent with the new examples. In this case, 
the new examples are ignored (included in the sets lE'^ and IE~) and nothing 
else happens. This has been done in this way because if the right solution is 
found soon, the algorithm is highly accelerated as it only performs a deductive 
checking of subsequent examples. 

In the case of a novelty or anomaly, the EH and PH sets are re-evaluated. 
The existing information for old evidence is reused, but the values are recom- 
puted for the new examples. Ignored examples of previous iteration can be taken 
into account, depending on a user option. The result is that some equations and 
programs can be removed because they are inconsistent. The optimality of the 
elements of both EH and PH is recomputed from the old ones and the covering 
of the new examples. Then the best solution is obtained again in order to see 
whether there is a solution to the problem. In this case, nothing is done. Other- 
wise, the procedure CoreAlgorithm is activated, which will generate the CRG’s 
for the new examples as we have seen before and will work with the old EH and 
PH jointly with the new CRG’s until a solution is found. 

This new algorithm allows a much richer functionality for FLIP. This can now 
accept a set PH of initial programs or theories Pi, P 2 , ..., a background the- 
ory B and the examples. If these initial programs are not specified, FLIP begins 
with no initial program set. If one or more initial programs are provided, FLIP 
will build EH from all the equations that form the initial programs (avoiding 
duplicate equations) and will generate a PH for each program. 

In this way, FLIP is at the same time: 

— a pure inducer: when there are no initial programs. 

— a theory reviser: when a unique initial program is given. The program will 
be preserved until an example forces to ‘launch’ the CoreAlgorithm. 

— a theory reviser /evaluator: when several initial programs are given and 
n examples are provided with a value of (positive) increment ality < n. 
In this case, the SelectBest function selects the best one wrt. the Zq" first 
examples. This program will be compared with subsequent examples and 
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could be changed accordingly. In the end, FLIP will indicate which initial 
program (or a new derived program) is better wrt. the n examples. If ig" > n 
FLIP will be just an evaluator if the theories are consistent with all the 
examples. 

— a theory evaluator: when the no-rev option is selected, several initial 
programs are given and n examples are given with a value of (positive) 
incrementality > n. In this case, the optimality criterion is applied and 
the best program wrt. the n examples is chosen. Consequently, FLIP simply 
indicates which of the initial programs is the best wrt. the evidence. The 
additional condition no-rev of the overall algorithm precludes the theories 
to be revised and new equations and programs to be generated. 

Initial theories, negative examples and background knowledge are optional for 
the incremental FLIP system. The positive examples are also optional because 
FLIP can also work as a theory evaluator for negative evidence only. 

At the present FLIP implementation, both Zg" and Zg are specified by the 
user, and z+ = I and i~ = 0. The use of z“ >0 does not affect considerably 
the efficiency of the algorithm since the CRG’s are generated only for the posi- 
tive examples. Moreover, negative examples are not necessary for classification 
problems with a finite number of classes, due to the nature of functional logic 
languages. In any case, the parts of a theory which the user wants to be fixed 
should be specified in the background knowledge. 

With regard to the automated evaluation possibilities of FLIP, it is possibly 
the most direct application for programming practice. As has been commented 
in [10], selection criteria from machine learning can be used to automatically 
choose the most predictive model of requirements, in order to reduce modification 
probability of software systems. Although in the next subsections we will center 
on generation and revision for small problems, the scalability of FLIP for large 
problems can be shown in the evaluation stage of software development. 



4 Results and applications 

To study the usefulness of our approach, we have performed some experiments 
using the FLIP system. 



4.1 Extending ILP and IFLP applications 

Apart from classical ILP problems, the first kind of application for which IFLP is 
advantageous is the dealing with semi-structured data, an area that is becoming 
increasingly more important. Most information in the web is unstructured or 
semi-structured. In order to do this, learning tools should be able to cope with 
this kind of data. 

FLIP is able to handle these problems because it can learn recursive functions 
and can work with complex arguments (tree terms) . 
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Example 1. Given an extended Mark-up Language (XML) document [1] which 
contains information about the good customers of a car insurance company (cus- 
tomers with a 30% gratification): 

<goodc> <name>john</name> <ha5_children/> </goodc> 

<goodc> <married/> <teacher/> <ha5_cellularphone/> </goodc> 

<goodc> <sex>male</sex> <teacher/> <name>j iirany</naiiie> </goodc> 

this document cannot be addressed by usual data-mining tools, because the 
data are not structured within a relation. Moreover the possible attributes are 
unordered and of different number and kind for each example. Nonetheless, it 
can be processed by our IFLP system FLIP by automatically converting XML 
documents into functional terms trees. In this case, the resulting trees would be: 
goodc (• (■ (A, name (John) ) ,has^ children) )=30 
goodc (• (• (• (A .married) .teacher) .has. phone) )=30. 
goodc (• (■ (• (A. sex (male) .teacher) .name (jimmy) ) ) )=30. 
goodc (■ (■ (A. sex (female) ) .tall) )=30. 
goodc (■ (■ (A. nurse) . sex (female) ) ) =30 . 

goodc (■ (■ (■ (A .browneye) . likes, coffee) .has. children) ) =30 . 
goodc (■ (■ (■ (A .has.children) .nurse) .has. phone) )=30 . 
goodc (■ (■ (■ (A. name (jane) ) .plays, chess) .has. children) )=30. 
goodc (■ (■ (■ (A .has.children) .name( joan) ) . speaks. Spanish) )=30 . 
goodc (• (■ (• (A .name (jane) ) . sex (female) )tall) )=30 . 
goodc (• (•(•(■ (A .name ( j immy) ) .teacher) . sex (male) ) .tall) )=30 . 
goodc (• (■ (• ( (A. teacher) .low. income) . is. atheist) .married) ) =30. 
goodc (• (• (• (A .name(mary) ) .has. children) .has. phone) )=30 
and the evidence for the other classes (customers with a 10% or 20% gratifica- 
tion), extracted from bad customers: 
goodc (■ (■ (A, sex (male) ) .tall) ) =10 . 
goodc (■ (■ (A. nurse) . sex (male) )) =20 . 
goodc (• (• (A. name (peter) ) .married) )=20 . 
goodc (• (■ (• (A. married) .policeperson) .has. phone) ) =10. 
goodc (• (• (• (A .name (char lie) ) . sex (male) ) .butcher) )=10 . 
goodc (• (■ (• (A .browneye) .likes, coffee) . sex (male) ) )=20 . 
goodc (• (• (• (A .plays.f ootball) .nurse) .has. phone) )=10 . 
goodc (■ (■ (■ (A . susEui) .plays, chess) .married) )=20. 

goodc (■ (■(■(• (A. butcher) . sex (male) ) .name (paul) ) . speaks, spauiish) ) = 10 . 
goodc (■ (■ (■ (A .name ( St eve) ) . sex (male) ) . speaks. Portuguese) ) = 10 . 
goodc (■ (■(■(• (A. name (pat) ) .married) . sex (male) ) .high, income) ) =20. 
goodc (■ (■(■(• (A. policeperson) .atheist) .has. phone) .married) ) = 10 
The FLIP system returns the following solution: 
goodc(-(X0.Xl)) = goodc(XO) 
goodc (-(XO. has jchildren)) = 30 
goodc(-(X0.sex(female))) = 30 
goodc (-(XO. teacher)) = 30 

Note that the solution is recursive and covers semi-structured datasets. 
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The next example, originally appeared in [3], can illustrate the application 
of the revision abilities of FLIP: 

Example 2. An optician requires a program to determine which kind of contact 
lenses should be used first on a new young client /patient. The optician has many 
previous cases available where s/he has finally fitted the correct lenses (either 
soft or hard) to each young client /patient or has just recommended glasses. The 
evidence is composed of 8 examples with the following attributes, parameter 
ordering and possible values for them: 



Age : 


#1 


young 


SpectaclePrescription : 


#2 


myopia, hypermetropia 


Astigmatism : 


#3 


no, yes 


TearProductionRate : 


#4 


reduced, normal 



The goal is to construct a program that classifies a new patient into the following 
three classes soft, hard, no. After feeding FLIP with the 8 lens examples of young 
patients from the database, it returns: 

lens(X0, XI, no, normal) = soft 
lens(X0, XI, yes, normal) = hard 
lens(X0, XI, X2, reduced) = no 

Consider that the optician wants to extend the potential clients. Now s/he deals 
with three different kinds of age: young, prepresbyopic and presbyopic. S/he adds 
16 new examples to the database with the results of the new clients. Using the 
new and old examples, FLIP revises the old program into the following one: 



lens(X0, hypermetropia, no, normal) = soft 

lens (young, myopia, no, normal) = soft 

lens(X0, myopia, yes, normal) = hard 

lens (young, hypermetropia, yes, normal) = hard 

lens(prepresbyopic, myopia, no, normal) = soft 

lens (prepresbyopic, hypermetropia, yes, normal) = no 
lens(presbyopic, myopia, no, normal) = no 

lens(X0, XI, X2, reduced) = no 

lens(presbyopic, hypermetropia, yes, normal) = no 



4.2 Speed-up analysis 

We have performed several other experiments with the new incremental version 
of FLIP to learn well-known problems with and without knowledge (see [4] for the 
source code of the problems) . The inclusion of incrementality can highly improve 
the induction speed. Table 3 shows the speed-ups reached when inducing these 
problems running FLIP. Times were measured on a Pentium III processor (450 
Mhz) with 64 MBytes of RAM under Linux version 2.2.12-20. They are expressed 
in seconds and are the average of 10 executions. The column Speed-up shows the 




244 C. Ferri-Ramfrez, J. Hernandez-Orallo, and M.J. Ramuez-Quintana 



Benchmarks 


Non-inc. 


Inc. 


Speed-up 


T^Rules 


T^Attributes 


sum 


6.01 


0.42 


14.30 


2 


2 


length 


13.96 


5.51 


2.53 


2 


2 


lenses 


12.17 


2.15 


5.66 


9 


4 


prod 


10.57 


2.22 


4.76 


2 -L 2 bkg 


2 


maxiist 


39.66 


2.27 


17.47 


2 4-3 bkg 


2 



Table 3. Benchmark results for io = 6 and 24 examples. The accuracy for all of them 
is 100% 




Start- up value 



□ Sum 
♦ Length 
T Prod 
A Lenses 
► Maxiist 



Fig. 1. Times obtained in the induction of some problems depending on the start-up 
value.® 

relative improvement achieved by the incremental approach for iq = 6, obtained 
as the ratio Non-Incremental -F Incremental. 

One can think that the time can strongly oscillate depending on the start- 
up value. Nevertheless, as we illustrate in Figure 1, the use of incrementality 
generally improves induction time whereas the start-up value only affects the 
speed-up. Figure 1 expresses the performances of rules of the resulting programs 
induced for different problems, depending on the start-up value. The results 
show that increasing start-up values give increasing times, because induction, 
especially CRG’s, are used more intensively. This is especially noticeable in the 
case of the maxiist problem, because the size of examples is large, and CRG’s 
are very time consuming. Although lower i values give the most efficient results, 

® The points surrounded by a circle indicate experiments where the accuracy is below 
100%. 
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there is also a risk of missing the good solution. This value is very dependent 
on the number of attributes. For instance, in the case of the problems with 2 
attributes, the optimal start-up value could be between 4 and 8 with some risk of 
missing the target program at low values. For the lenses problem (4 attributes) 
the optimal start-up value could be between 7 and 20. This suggests that the 
start-up value can be estimated from the number of attributes (which, moreover, 
is the only parameter that is known a priori). 

Let us perform a more detailed study for a larger problem: the monksl prob- 
lem. This problem is a popular problem from the UCI ML dataset repository [16] 
which defines afunction such that monfcsl(_, 1,_) and monfcsl(X, X,_, _,_,_) 
It has a larger number of examples to essay and the function depends on 6 at- 
tributes. The following table shows, as expected, that the speed-up increases as 
long as the number of examples increases: 



Benchmarks 


Non-inc. 


Inc. 


Speed-up 


^Examples 


T^Rules 


Attributes 


monksl 


528 


345 


1.53 


25 


2 


6 


monksl 


1075 


344 


3.13 


50 


2 


6 


monksl 


2012 


347 


5.8 


100 


2 


6 


monksl 


3286 


350 


9.39 


150 


2 


6 


monksl 


4598 


351 


13.10 


216 


2 


6 



Table 4. Benchmark results for io = 14, and variable number of examples for the 
monksl problem. The accuracy for all of them is 100% 



Monksl 
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■D 3000 

c 

o 2500 
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14 25 50 75 100 125 150 175 200 216 

Start- up Value 



Fig. 2. Times obtained in the induction of the monksl problem depending on the 
start-up value. 
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We have also measured the speed-up for different values of the start-up value, 
from 14 to 216. Figure 2 shows the results. Values below 14 are quite irregular 
but, in general, are worse than those for 14. 

5 Conclusions and future work 

In this paper we have extended the induction of functional logic programs to 
an incremental framework. Incremental learning allows the handling of large 
volumes of data and can be used in interactive situations, when all the data are 
not received a priori. 

Although incrementality forces the introduction of revision processes, these 
can be of different kinds. According to the complexity of revision, many ap- 
proaches [20] [22] have been based on minimal revisions, which usually ‘patch’ 
the theory with some factual cases to cover the exceptions. These approaches 
are more efficient in the short term but, since revisions are minimal, the re- 
sulting theories tend to be more a patchwork and more frequently revised with 
time [11] than a coherent hypothesis. On the contrary, our approach is based 
on deep revisions (the whole inductive core algorithm is reactivated) until the 
best hypothesis reaches a good score according to the evaluation criterion. This 
motivates that theories can be revised either by anomalies or novelties, and the 
resulting theories output by FLIP are more coherent. 

As future work we plan to implement ‘oblivion’ criteria in order to forget 
old data that are redundant or that have been used in theories which are well 
reinforced. ‘Stopping’ criteria should also be introduced in order to increase 
the speed-up. Currently the speed-up is obtained because in the moment that a 
hypothesis is stable, the rest of positive evidence is just checked deductively, and 
the inductive process (the costly one) is not used. Among the stopping criteria we 
are investigating two heuristics: one based on the number of iterations that the 
hypothesis has remained unchanged and the other one based on the optimality 
of the hypothesis. These could also be used in order to work with non-constant 
incrementality values (currently = 1). In the same way, we want to study the 
relation between FLIP performance and the use of different evaluation criteria 
by using the evaluation mode of FLIP and a generator of examples that has 
been recently developed. More ambitiously, we are working on an incremental 
redesign of the CRGs in order to cope with a great number of attributes. In 
this way, incrementality would be horizontal as well as vertical, allowing the use 
of complex and large examples (lists, trees, etc.) that in many cases cannot be 
handled non-incrementally. This would extend the range of applications of the 
FLIP system to other kinds of problems: data-mining and program synthesis. 
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Abstract. We propose a constraint-based formulation of Hindley/Milner 
style type inference system as opposed to the standard substitution-based 
formulation. This allows us to make important distinctions between dif- 
ferent phases of type inference; Constraint generation/propagation, con- 
straint solving, constraint simplification and term reconstruction. The 
inference system is parametric in the constraint domain, covering a wide 
range of application domains. A problem, incompleteness of substitution- 
based inference, identified by A. J. Kennedy can be solved naturally by 
employing a constraint-based view of type inference. In addition, our 
formulation of type inference can easily be tailored to different inference 
algorithms such as W and M. On the technical side, we present concise 
soundness and completeness results. 



1 Introduction 

Type systems are important in the design of programming languages and type- 
based program analyses. The Hindley/Milner system has proved to be one of the 
most popular and successful type systems. One of the most important features 
of the Hindley/Milner system [Mil78] is decidable type inference. Type inference 
algorithm W, introduced by Milner, reports a type for a given program. Milner 
could prove that algorithm W is sound, i.e. every reported type is a valid type. 
In [Dam85], Damas proved that algorithm W is complete, i.e. for any typable 
program algorithm W will report an answer or otherwise will report failure. Most 
notably, algorithm W infers principal types. A principal type subsumes all other 
types we can possibly assign to a given program. 

In [LY98], Lee and Yi prove soundness and completeness of algorithm A4 
which is a top-down formulation of algorithm W. Both algorithms yield the 
same result but algorithm A4 seems to be the better choice if the program is 
ill-typed. Lee and Yi formally prove that algorithm A4 reports type errors earlier 
than algorithm W. In [LYOO], Lee and Yi propose a generic scheme for inference 
algorithms for the standard Hindley/Milner system which contains algorithms W 
and A4 as special instances. 

Extensions of the Hindley/Milner system with equational theories and its 
inference systems were studied in [Rem92,Ken96]. A more general approach was 
considered by Odersky/Sulzmann/Wehr. In [OSW99], Odersky et al. introduce 
a generic version of algorithm W parameterized in the constraint domain. Un- 
der certain conditions on the constraint domain, type inference yields principal 
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types. Several application domains such as [DHM95,Oho95,NP95,AW93] have 
been studied in [OSW99] and [SulOOa]. 

As observed by Kennedy, algorithm W is incomplete in case of a variation of 
the Hindley/Milner system that deals with physical dimensions. 

Our work extends the approaches of Lee/Yi, Remy, Kennedy and Oder- 
sky/Sulzmann/Wehr. We present a constraint-based inference scheme for Hind- 
ley/Milner style systems which allows for flexibility in the following different 
components of type inference: 

1. Constraint generation: We need to generate a correct set of constraints which 
represents the possible solutions to the typing problem. 

2. Constraint solving: Our inference system is parametric in the constraint 
solver. Solving of constraints must be decidable to retain decidable type 
inference. 

3. Constraint propagation: Different inference algorithms such as W and A4 
can be modelled by different constraint propagation policies. 

4. Constraint simplification: By simplification, we mean the task of achieving 
certain optimal syntactic representation forms of constraints. This is impor- 
tant to ensure efficient type inference. 

5. Term reconstruction: Type inference keeps all typing information in con- 
straint form. However, the type system itself might enforce certain term 
representations of types. Completeness holds if we can reconstruct best term 
solutions to constraint problems. 

Specific inference algorithms fall out by instantiating the individual components 
appropriately. We believe it is important to make a distinction among the differ- 
ent components. This helps in establishing concise soundness and completeness 
results which are parametric in the individual components. In particular, our new 
formulation of type inference provides a natural solution to Kennedy’s problem. 

We start in Section 2 with some background information about constraint 
systems and HM(X). HM(X) is a general framework to study Hindley/Milner 
style type systems parameterized in the constraint domain X. Section 3 intro- 
duces our general inference scheme formulated as a constraint-based inference 
system. We give an axiomatic description of sound and complete constraint prop- 
agation policies and provide a range of possible instances. In Section 4, we review 
Kennedy’s problem and present a new formulation of term-based inference sys- 
tems. We conclude in Section 5. 

A detailed exposition including full proofs can be found in [SulOOb] . 

2 Preliminaries 

2.1 Constraints and Substitutions 

Constraint systems are defined in terms of a first-order logic where A stands 
for logical conjunction and 3a. for existential quantification of a sequence of 
variables Oi, . . . ,a„. Given a set Var of type variables and a subset U of Var, 
we define 3U.C = 3V.C where V = Var\U. The domain is defined by a term 
algebra T which also describes the language of types. We assume that at least 
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we are given a primitive predicate (=) which expresses type equality between 
members of the term algebra T . C D and C = D denote model-theoretic 
consequence and equivalence among constraints. We will always assume that 
for a given constraint system there exists a model A4 which satisfies the laws 
of the constraint system. However, we leave the specific model A4 implicit. For 
example, we write ^ C to denote that C is valid under Af . Given a constraint C, 
then fv{C) = {a \ 3a. C ^ C} is the set of free variables in C. A constraint C is 
satisfiable iff ^ 3fv{C).C. 

A substitution <j) = [f/d] mapping type variables to (monomorphic) 
types Ti can always be viewed as the constraint (oi = ti) A . . . A (a„ = r„). 
In the same way, a type r can be viewed as the type variable a under the 
constraint (a = t). Applying substitution f = [f/a] to constraint C can be ex- 
pressed within the language of constraints via conjunction and existential quan- 
tification 3a. We have the following identity: (j)C = 3a. {{f = a) A C). We use 
the convention that constraints 4>,ip, . . . refer to substitutions in constraint form. 
The domain of a substitution equals the set of free variables of a constraint. We 
have the following identity dom{4>) = fv{4>). Syntactic substitutions can eas- 
ily be expressed in terms of the constraint language. We dehne </>(a) = r iff 
\= 3U.{(j) A (a = r)) where U = fv{4>). 



2.2 Normalization 

We introduce the concept of normalization as an extension of constraint solving 
and unification. Note that we only consider constraints over Herbrand terms, 
therefore we do not need to rely on more advanced solving methods such as 
semi-unification and higher-order unification. 

Given a constraint system X over a term algebra T, we say S is the set of 
solved forms in A iff 5 is a subset of all satishable constraints in X. 

Given constraints C, D and cf in X, then C A 4> is a normal form of D iff 
C € S and C A j= D. We say C A is prineipal if for all normal forms C' A (j)' 
it holds that 3U.{C A 4>') h 3U.{C A <f) where U = fv{D). 

Example 1. Gonsider the standard Herbrand constraint system. We take S to be 
the set consisting only of true, which is represented by the empty token set {}. 
Then, a principal normal form corresponds to a most general unifier and a normal 
form corresponds to a unifier of a constraint problem. 

Principal normal forms are unique modulo semantic equivalence. Hence, it is 
possible to dehne a well-dehned function normalize from constraints C to normal 
forms: 

normalize{D) 

= C Af) ii C A xf is a principal normal form of D 
= fail if no normal form exists 

The property of having a principal normal form extends to constraint sys- 
tems. Given a constraint system X over a term algebra T and a set of solved 
constraints S in X, we say the constraint system X has the principal constraint 
property if for every constraint C in X, either C does not have a normal form or 
C has a principal normal form. 
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2.3 The HM(X) Ftamework 

We assume, we are given a constraint system X over a term algebra T and a set 
S of solved forms in X. The typing rules and a description of the language of 
expressions and types can be found in Fig. 1. Types are members of the term 
algebra T where there might be other constructors besides This is expressed 
by the symbol 3. Type schemes include a constraint component C which restricts 
the types that can be substituted for the type variable a. The language of terms 
is exactly as in [DM82]. That is, we assume that any language constructs that 
make use of type constraints are expressible as predefined values, whose names 
and types are recorded in the initial type environment Fq. 

Typing judgments are of the form C,F h e : a where C is in X, T is a type 
environment associating free variables with their type, and ct is a type scheme. 
A typing judgment is valid if it can be derived by application of the typing rules. 

We restrict the set of constraints allowed to appear in typing judgments and 
type schemes to the set S of solved forms. Given a constraint C appearing on 
the left-hand side of the turnstile or in a type scheme, then there must be a 
constraint D G S such that C and D are equivalent. 

Most rules are straightforward extensions of the standard Hindley/Milner 
rules. In rules (Abs) and (Let), the type environment F^ denotes the type en- 
vironment obtained from F by excluding variable x. The formulation of the 
(V Elim) rule is similar to previous formulations. The only valid instances of 
a type scheme Va.D ^ r are those that satisfy the constraint part of the type 
scheme. The formulation of the (V Intro) rule is one of the novelties of the HM(X) 
system. Type variables are not only bound in the type component but in ad- 
dition also in the constraint component through the existential quantifier. Rule 
(3 Intro) is motivated by the following logical rule: Va.(P ^ Q) = {3a. P) Q 
where a ^ fv{Q). The outermost universal quantification of the free type variable 
a in the judgment C,F h e : a can be moved to the constraint part, if a does 
only appear in the constraint part. This allows type variables that only appear 
in the constraint part of typing judgments to be hidden. 

Unlike standard treatments of Hindley/Milner style systems, there is also a 
subsumption rule (Sub), which allows us to derive term e with type t' if we 
can derive term e with type r and type r subsumes type t'. The subsumption 
relation ^ is determined by the constraint system X, and is assumed to satisfy 
the standard axioms for a partial ordering plus the contra-variance rule, see 
Fig. 1. Except for these conditions, the choice of ^ is arbitrary. Note that the 
subsumption relation ^ is a generalization of other relations such as type equality 
or subtyping. 

The relation C h* a < a' states that type scheme a is smaller than type 
scheme a' with respect to the constraint C. Rule (SubI) connects the relation h® 
to the entailment relation |=. Rules (V ^) and (^ V) describe how to deal with 
type schemes. The definition is standard. 

We maintain that an instance of the HM(X) system is defined by the five- 
tuple (X, T, S, Fq) which we commonly refer to as HM(X) or simply X. 

Example 2. The Hindley/Milner system is an instance of our HM(X) type system 
framework. Take X to be the Herbrand constraint system HERBRAND over the 
algebra of types t. HERBRAND consists only of primitive constraints of the 
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Expressions 

V ::= X I \x.e 
e ::= v I e e I let a; = e in e 



Types 

r ::D a I t ^ t 
a ::= r | Va.C r 



Typing rules 



(Var) C,r \- x:a {x : a G T) (Sub) 



C, r h e : r C |= (t ^ t') 
C, r h e : r' 



C, Fj:.x : T e : t' 
C, Fx \- Xx.e ■. T ^ t' 



C,F \- ei : n ^ T 2 
(App) C,F \- 62 : n 
C, -T h 6162 : T2 



he:cr CAL»,ri-e:r 

(Let) C,Fx.x : a h e' : r' (V Intro) a ^ fv{C, F) 

C, Tc h let a; = e in e' : r' C A 3a. D, The: Va.D => r 



C,r h e : Va.T ^ r 
(V Elim) C h [f/a]D 

C,F \- e \ [f/a]r 



C, r h e : 0 - 
(3 Intro) a ^ /u(T, a) 
3a. C, T h e : cr 



Subsumption rules 



C^(a = a') 

C \= (a ^ a') A (a' ^ a) 



C” 1= (® — 

C h (a = a') 



C 1= (ai ^ Q 2 ) C 1= (o 2 A Q3) C 1= (a) A qi) C |= (02 A Q2) 
C 1= (ai ^ as) C 1= (ai ^ 02 A a) ^ a' 2 ) 

Instance relation 



(SubI) 



g h (r ^ r') 
C h* r -< r' 



CAOh^g-^T tu(cr, C) C h^ [r/g]r ^ r' C \= [r/a]£> 

C A 3g.T P cr r< (ya.D ^ t) ^ C h' (Va.T 



Fig. 1. Logical Type System 
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form (r = t') where r and t' are elements of a term algebra T. Equality in 
HERB RAND is syntactic, T is a free algebra. Take (^) to be (=). Take the 
set of solved forms to be the set consisting only of true, which is represented 
by the empty token set {}. Then the only type schemes arising in proof trees 
of valid typing judgments are of the form Vct.{} ^ cr, which we equate with 
Hindley/Milner type schemes Va.cr. It is easy to convince oneself that a judgment 
T h e : (7 is derivable in Hindley/Milner if and only if {}, T h e : ct is derivable 
in HM(HERBRAND). 

For the purpose of this paper we omit a further discussion and refer to previous 
work [SulOOa,OSW99], 

3 Constraint-Based Inference 

We consider type inference in the purely constraint-based fragment of HM(X) 
where the set S of solved forms consists of all satisfiable constraints in X. Con- 
straint solving requires only a satisfiability check. 



(Var) 


X : {\/a.D ^ t) £ r 

C,r,x:a (C A 3a.((a = r) A D)) 


(Abs) 


Cl, 7k. a; : ai,e : 02 D (Ci,02) € PartSol{r.x : Qi,e) 

D' = D A (qi ^ 02 ^ q) a C 




C,r^,\x.e : a D' 


(App) 


Cl, r, ei : oi Di (Cl, oi) G PartSol{r, ei | T, 6162) 

C2, r, 62 : 02 L»2 (C2, 02) G PaHSol{P, 62 | P, 6162) 

D — D\ A D 2 A (oi ^ 02 ^ o) A C 
C,r,ei62 : 0 F^-f D 


(Let) 


Cl, r, e : 01 F"^ Di (Ci, oi) G PartSol{P, e) 
Di,P,ai F»"" (D[,ai) 

C2, P^.x : crj , e' : 02 F"^ D 2 (C2, 02) G PartSol{P^.x : crj , e') 
D = D'l A D 2 AC A (02 ^ 0) 




C,A,let a: = ein e' : o D 


(3 Intro) 


C,P,e:a F™^ D fv{P, 0) 

C,P,e:a 3a.D 




Fig. 2. Constraint-Based Inference 
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3.1 A General Inference Scheme 

The inference system is given in Figure 2. Inference clauses are of the form 

C,r,e: a h™-'" D 

with constraint C, type environment T, expression e and type variable a as 
input values and constraint D as output value. Premises of inference clauses 
should be read as logical premises which need to be fulfilled in order to derive 
the conclusion. Note that input constraints are passed up in the inference tree 
whereas output constraints are passed down in the inference tree. We consider 
the inference tree to be up-side down with the root node at the bottom. Com- 
monly, C constraints denote input constraints and D constraints denote output 
constraints. The inference rules preserve satisfiability of the output constraints. 
Therefore, satisfiability can be checked at any stage of the inference process at 
latest when reporting the result to the user. 

All rules except (3 Intro) are syntax-directed. This rule allows us to hide 
some set of type variables and is justified by the logical typing rule (3 Intro) 
from Figure 1. Commonly, rule (3 Intro) is applied aggressively, so that useless 
variables do not appear in the final result. 

The novelty of our formulation is that we allow partial solutions to be passed 
up in the inference tree in rules (Abs), (App) and (Let). As an example, we 
consider the standard Hindley/Milner system. 

Example 3. We are given the following program: 

e = {Xf.f3)(Xx.x^ + 1) 

ei 62 



Inference in style of algorithm W proceeds by inferring the type for the two 
subexpressions ei and 62 - We find ei : (Int — ^ a) — > a and 62 : Int ^ Int where a 
is a new type variable. The final result for expression e is formed by generating 
the type constraint (Int — > a) ^ a = (Int ^ Int) — > f3 where /? is a new type 
variable. 

In contrast, inference in style of algorithm A4 carries a type constraint from 
the context of the expression. This imposes the constraint that expression Ci 
must be a function type. Given the result (Int ^ a) ^ a for expression ei, 
algorithm A4 imposes the constraint that I nt a must be a partial solution of 

the result of expression 62 - 

We find that both algorithms yield the same result, however they differ in 
the way type information is propagated during type inference. 

Given our constraint-based formulation of type inference, it immediately fol- 
lows that there are a wide range of different inference algorithms possible. A 
discussion can be found in the following section. 

First, we need to characterize all valid partial solutions we are allowed to pass 
up in the inference tree. To ensure completeness of inference, a partial solution 
must subsume all other possible solutions for a given typing context. 
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Definition 1 (Ordering Relation). Given a typing problem (-T, e) and eon- 
straints Ci,C2 and types ti,T 2- <r (C'2,T2) iffC2 ^ A (n A T2)) 

where U = fv{C2, -T, T2) . 

For a fixed typing problem {F, e), we write (Ci, ti) < (C2, T2) for simplicity. 

The next lemma states that our ordering relation preserves solutions. 

Lemma 1 . Given {Ci,Ti) <r (C2,T2) such that Ci,F \- e : ti is valid. Then 
C2,F \~ e : T2 is valid as well. 

Definition 2 (Partial Solutions). Given constraints C and C' , types r and 
t' , expression e and type environment F. Then, (C,t) € PartSol{C , F h e : 
t') iff ( 1 ) C' ,F \- e : t' is valid and there exists a constraint D such that 
( 2 ) C A D, F [- e : T is valid and ( 3 ) (C A D, r) <r {C , t'). 

(C,t) € PartSoliC ,F h e : a') iff for each fi if C' h* a' A p then 
{C,t) G PartSol{C',F h e : r'). 

(C,t) G PartSol{F,e) iff {C,t) G PartSoliC', F h e : r") for each (C",r")- 

Example 4 - Consider expression Xx.x + 1 in Example 3 . We immediately know 
that ((oi = 02 — *■ 03),cti) is a partial solution. 

Definition 3 (Partial Solutions and Context Information). Given con- 
straints Cl, C and C , types t\, t and t' , expressions e and e! and type environ- 
ments F,F' . Then, {Ci,ti) G PartSoliF' ,e' \F,e) iff {Ci,Ti) G PartSoliC ,F' \~ 
e' : t' \ F, e) for each (C", r'). 

(Ci.n) G PartSoliC, F' h e' : P\F,e) iff iCi,Ti) G PartSoliC, F' h e' : 
t') and there exists a derivation with final judgment C ,F h e : r" for some 
constraint C" and type t" such that judgment C,F' h e' : t' appears in an 
intermediate step. 

Example 5 . In Example 3 , the expression ei has ((cti = 02 — > 03), Oi) as a 
partial solution given the context information 6162. 

To ensure soundness, we need to generate constraints (oi ^ 02 A a) (in 
case of the (Abs) rule), (oi F a2 ^ a) (App) and (02 ^ cr) (Let) and pass 
these constraints down the inference tree. Note that these constraints might 
already be entailed by the propagated constraints, and therefore need not be 
generated again when forming the output constraints. In general, we assume 
that constraints can always be replaced by semantically equivalent constraints. 

Quantification of type variables is tied to the (Let) rule. We need to in- 
troduce a generalization relation that yields the generalized type scheme and 
the generalized constraint. Given constraints C, Co G S, a type environment F 
and types r, CTo. Then C,F,t h®®” (Co,cto) iff Co = Bd.C = Ci A 3 a.C 2 , 
(Jo = Vd.C'2 ^ T, a ^ fviC\,F) for some constraints Ci,C2. Note that the 
above requirements can always be fulfilled by taking C\ to be true. However, de- 
pending on the actual constraint system used, there might exist better strategies, 
which keep the constraint in the generalized type scheme smaller. 
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3.2 Soundness and Completeness Resnlts 

Soundness of inference is straightforward. 

Theorem 1 (Sonndness of Inference). Given a type environment F , an ex- 
pression e, two constraints C,D and a type variable a. If C,F,e : a D 
then D,r \~ e : a and D \= C. 

The completeness result is restricted to type schemes that have a type in- 
stance. We say a is realizable in C if there exists a type t such that C h* a <t. 
This extends to type environments. 

Theorem 2 (Completeness of Inference). Given C',F h e : r' such that F 
is realizable in C' and {C, a) G PartSol{C' , F h e : r'). Then C,F,e: a D 
such that C' ^ 3F.{D A (a ^ r')) for some constraint D. 

3.3 Constraint Propagation Policies 



true,Tc.a; : Qi,e : 02 I 
D' = D A (qi ^ 02 a q) 



Qi, 02 new 



tme,r,,A®.e : o D 



true, r, ei : oi L»i 

true, r, 62 : 02 D2 

(App-W) D = D\ A D2 A (oi A 02 ^ o) 
ai, 0:2 new 

true, r, 6162 : o P"-'' D 



C",T,.a; : 01,6 : 02 P"-^ D 
C' = C A (oi ^ 02 A o) 
oi, 02 new 

C,A,A®.6 : o D 



C",r, 61 : 01 P"^ Di 
C' = 3 o^ a" .C A (oi A o^ ^ a") 
true, r, 62 : 02 D2 

D = 7 Ai A D2 A CA 
(oi A 02 ^ a) 
oi, 02 new 
C,r,ei62 : o P"-'' 



C",r, 61 : oi P"^ Di 
C' = C A (oi A 02 ^ o) 

rA C",r ,62 :0^ P"^ i?2 

(App-*l) 

ai, 0:2, 0^2 

C,r, 6 l 62 : O h™-'' L»2 



(App-M" 



true, r, 62 ; 02 A>i 

C", r, 61 : 01 D2 

C' = Di A CA 

(ai Q!2 ^ o;) 
ai, a2 new 

C,r,6l62 : O D2 



Fig. 3 . Inference in W and M Style 



In [LYOO], Lee and Yi propose a generic scheme for inference algorithms for 
the standard Hindley/Milner system. It is straightforward to incorporate their 
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inference algorithm scheme into our inference system. Note that in addition our 
inference scheme applies to a much wider range of Hindley/Milner style systems. 

In Figure 3, rules (Abs-W) and (App-W) model inference in W style. Rules 
(Abs-A^) and (App-A^) model inference in A4 style. Note that the constraint (ct^ ^ 
02 ) is essential for subtyping but could be omitted in the case of an HM(X) in- 
stance where ^ models type equality. 

Our formulation allows for several variations of inference in A4 style. A more 
conservative propagation policy is formulated by rule (App-Al'). With the exis- 
tential quantifier, we can hide any specific details of ei’s argument and function 
type. The only information that we propagate up the inference tree is that ex- 
pression 6i must be a function type. It is also possible to let information flow 
from the argument to the function site, see rule (App-Al"). This kind of con- 
straint propagation policy does not seem to be covered in [LYOO]. 

Soundness and completeness of inference can be re-established if the inference 
rules preserve partial solutions and generate a correct set of constraints. A proof 
can be found in the Appendix. 

An alternative proof method would be proving a new inference algorithm 
correct wrt. a standard algorithm, i.e. for any given program both algorithms 
generate equivalent constraints. However, this method does not work well if we 
propagate typing information up in the inference tree. To ensure completeness, 
it is crucial to formally prove that the propagated typing information does not 
restrict the set of possible solutions. 

4 Term-Based Inference 

We consider inference for the term-based fragment of HM(X) where the set S of 
solved forms is possibly more restricted. 

As observed by Kennedy, algorithm W is incomplete in case solutions to 
constraints (substitutions in his case) are represented in the language of types 
(or terms in our terminology). 

We cite the following example given by Kennedy [Ken96]. He introduces a 
Hindley/Milner style system that deals with physical dimensions. In addition to 
the usual types there are dimension types. ^ We find the following type language: 

Dimensions d ::= a \ i{d) \ prod{d, d) | 1 1 M | T 
Types r ::= a I dimd I T ^ T 

where the dimension constructor z(-) corresponds to the inverse of a dimension 
and prod{-, ) to the product of two dimensions. Dimension constants are 1 for 
the unit measure, M for the mass dimension and T for the time dimension. 

Example 6. Consider the following initial type environment: 

r = {kg : dimM, s : dimT, pair : Vti, t 2 di ^ t 2 ^ (H A 2 ) 
div : Vdi, d 2 - dimprod(di, c? 2 ) ^ dimdi ^ dimd 2 } 

^ Please note, we consider physical dimensions such as mass, time, length, etc. It would 
also be possible to consider unit types such as feet, meter and so on which are simply 
finer-grained versions of dimensions. 
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where kg and s are some basic dimensions, pair is the pairing operator and div 
is a primitive operation on dimensions. Consider the program: 

e = Ax. let y = divx\n pair{y kg){y s) 

Note that function y is applied to arguments of different type, hence must be 
polymorphic. Consider typing e under the type environment F . In an interme- 
diate step we find: 

r.x : dimprod((ii, ^2) b divx : dimdi — > dimc?2 (1) 

It is not possible to quantify over the type variables di and ^2 because di and 
d2 also appear in the type environment. Hence, we can not give function y a 
polymorphic type. This suggests that program e is not typable in the dimension 
type system. However, we can derive another type for divx under the same type 
environment: 



r.x : dimprod{di,d2) b div x : dim prod{di , ds) ^ dim prod^i^ds) , d2) (2) 

We have simply instantiated d\ with prod{di, d^) and d2 with prod(i{d3), d2). Di- 
mension types obey the laws of an Abelian group. For details we refer to [Ken96] . 
For instance, it holds that 

1= {prod{prod{di , ds) , prod{i{d 3 ) , d2)) = prod{di,d2)) 



This ensures that the type environment remains unchanged. However, it is now 
possible to quantify over the free type variable da in typing judgment (2). Then 
program e becomes typable. We find that 



r b e : Vdi, d2- dimprod(di, ^2) 



(dimprod(z(M), prod(di, c?2)), 

dim prod{i{F),prod{d\, ^2))) 



(3) 



The above example shows that the standard substitution-based inference 
algorithm is incomplete. This can be fixed by switching to a constraint-based 
inference algorithm where substitutions are represented in the domain of con- 
straints. 

The dimension type system belongs to a class of systems where constraint 
solving relies on a unification-based approach. In addition to the inference rules 
in Figure 2 we introduce an additional term reconstruction step: 



(Normalize) 



C,r,e : a b™-^ D D' A 4 > = normalize{D) 
C,r,e: a b“^ D' A </> 



The above rule invokes a normalization function which returns the normalized 
constraint represented as a constraint and residual substitutions. We assume 
that rule (Normalize) is applied at latest in the final inference step. Note that 
substitutions are represented in the domain of constraints and not in the do- 
main of types. This is crucial to circumvent problems such as demonstrated by 
Kennedy’s example. 

Results of this section directly follow from the results in Section 3, hence 
are independent of a specific constraint propagation policy. We explicitly switch 
from a constraint representation to a term representation, when presenting the 
result of inference. 
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Theorem 3 (Soundness of Inference). Given an HM(X) type system in- 
stance where X satisfies the principal constraint property. Given a type environ- 
ment r, an expression e, constraints a type variable a and C,F,e : 

a P"/ D' A'lp'. ThenD',xp'r h e:-tp'{a). 

Term-based inference computes principal types if minimal term solutions 
(i.e. principal normal forms) exist. 

Given an instance X of the HM(X) type system. X satisfies the principal type 
property iff the following holds: Given a pair (T, e) such that C", T h e : P for 
some constraint C' and type scheme o' . Then there is a constraint C and a type 
scheme a such that (1) C,F h e : a and (2) Given C", T h e : a' then C' \= C 
and C' h* a < ct' ■ 

The pair (C, a) is called a prineipal type. Gommonly, the constraint compo- 
nent equals true. 

Theorem 4 (Principal Types). Given an instanee of the HM(X) system 
where X satisfies the prineipal constraint property. Given a closed typing judg- 
ment true, F \- e : a where F is realizable in true and a fresh type variable a. 

Then, there exist constraints D and f such that true, F,e : a D A f, 

C,(j)F,(j){a) P®" (true, (To) and h* UoFiCf for some type seheme (Jq. 

Note that this is a straightforward extension of the notion of principal types 
found in the Hindley/Milner system. In the standard Hindley/Milner system, 
principality states there is one unique type (a principal type) from which all 
other types can be generated (by building generic instances). In contrast, a 
principal type in HM(X) represents rather a class of types which are semantically 
equivalent. 

Example 7. Gonsider the program Xx.x in a variation of the Hindley/Milner 
system where the set of solved forms equals all satisfiable constraints. One 
obvious principal type would be a\ = Va.a ^ a. However, the type a 2 — 
Va,/3.(a = (i) =A a ^ (3 would be another possible candidate. It holds that 
true, 0 h Xx.x : cri and true, 0 h Xx.x : (T 2 and h* ^ (T 2 but also h* ^ (Ti. 

This shows there is no unique principal type in a variation of the Hindley/Milner 
type system where the set of solved forms equals all satisfiable constraints. 

A unique principal type can be computed if principal normal forms are syn- 
tactically unique. It is straightforward to prove that principal normal forms 
are syntactically unique if for each constraint C G S there is no other con- 
straint D G S such that C and D are semantically equivalent. 

Finally, we come back to Kennedy’s example. 

Example 8. The theory of dimension types possesses most general unifiers, see [LBB84] . 
In case of dimension types we are faced with the problem of having several dif- 
ferent term representations of a type for a given term under the same type 
environment, see judgments (I) and (2) in Example 6. Both judgments have the 
same information content but a different syntactic representation. The inference 
algorithm simply picks the wrong syntactic representation and gets stuck. 

If we allow dimension types to appear in constraint form, we find the following 
variation of typing judgment (1): 

{a = prod{d\, ^ 2 )), F.x : a h divx : dimdi dim(i 2 . 
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If we unify with the constraint {a = prod{di, d, 2 )) we would obtain judgment (1) 
again. The representation of substitutions in constraint form leaves type variables 
d\ and d 2 free in the type environment. Hence, we can quantify over these type 
variables. The function y has now the desired polymorphic type Wdi, d 2 -{a = 
prod{di, d 2 )) ^ dirndl ^ dimd2- The following typing judgment is a variation 
of judgment (3): 



(a = prod{d[,d' 2 )) A {d[ = M) A (d^ = /3)A 
(a = prod{d”, d' 2 )) A (d" = T) A (d'2 = 7) 



The: dim a — > (dim /3, dim 7) 



Unification would result in judgment (3). 



5 Conclusion 

We have showed how to extend and combine the approaches of Odersky et al. [OSW99] 
and Lee and Yi [LY98]. Our motivation was to provide a flexible and general 
Hindley/Milner inference system which allows us to separate the essential com- 
ponents of type inference: Constraint generation, constraint solving, constraint 
propagation, constraint simplification and term reconstruction. 

The main idea of our approach was to represent all typing information in the 
domain of constraints. We believe that issues such as syntactic representation 
forms of types are important for user interaction but are irrelevant when per- 
forming type inference. In particular, our constraint-based formulation of type 
inference leads to a natural solution of the problem pointed out by Kennedy. We 
could improve the inference results in [OSW99] and can finally state that the 
principal types property implies principal types (see Theorem 4) . 

Our constraint-based formulation of type inference has also proved to be use- 
ful when considering different inference algorithms such as W and A4 . We gave an 
axiomatic description of sound and complete constraint generation/propagation 
policies which improves work by Lee and Yi [LYOO]. 

In this work, we focussed on the abstract inference framework. We believe 
that our general inference scheme makes it easier to design new Hindley/Milner 
style inference algorithms and furthermore allows to re-establish corresponding 
soundness and completeness results in a uniform and concise way. 

There are many possible avenues for future research. We consider it particu- 
larly interesting to apply our inference scheme to type-based program analyses. 
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A Basic Lemmas 

The following lemmas are used in the correctness proof of inference in Ai style. 

Proofs are straightforward by induction over the derivation h . 

We say a subsitution (f> is consistent in F if for each {x : a) G F the constraint 

component in (fa is satisfiable. 
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Lemma 2 (Substitution). Given C,F h e : r and a substitution (p such that 
4>C is satisfiable and p is consistent in F. Then pC, <pF h e : pr. 

Lemma 3 (Weakening). Given C,F h e : r and a eonstraint D sueh that 
C A D is satisfiable. Then C A D,F h e : r. 

Lemma 4 (Canonical). Given C,F h e : r. Then C A {a = t),F h e : a 
where a is a new type variable. 

Lemma 5 (Replacement). Given C^F^.x : r h e : r'. Then C A {a = 
t),Fx.x : a h e : r' where a is a new type variable. 

B Proof of Correctness of Inference in Al-style 

We show that the inference rules in Figure 3 are correct, i.e. preserve partial 
solutions and generate a correct set of constraints. For simplicity, we only prove 
correctness of rules (Abs-At) and (App-At). The other proofs are similar. 

An easy observation shows that rules (Abs-At) and (App-At) generate a 
correct set of constraints. It remains to prove that both rules preserve partial 
solutions. In case of the (Abs-Af) rule we find the following situation: 

C',Fx.x : ai,e : D C' = C A {a\ ^ a 2 A ex) «i,a 2 new 

C,F^,Xx.e : a D 

By assumption (C, a) G PartSol{Fx, Xx.e). We have to show that (C A {a\ — > 
CX 2 A ex),a 2 ) G PartSol{Fx.x : ai, e). 

By assumption we have the following (normalized) derivation 



C A D, Fx.x : Ti h e : T 2 

C A D,Fx b Xx.e : n — > T2 C A D \= {t\ ^ T2 A ex) ( 4 ) 

C A D,Fx b Xx.e : a 

for some constraint D and types ri , T2 . Application of the Weakening, Canonical 
and Replacement Lemmas (see Appendix A) yields C A {a\ ^ «2 A a) A (ai = 
Ti) A (tt2 = T2) A D,Fx.x : ai be: a2. This shows part (2) of the definition of 
partial solutions. 

For part (3), we assume given a valid C',Fx.x -.ax b e : rb We can derive 
that C',Fx b Xx.e : a\ t' . {C,a) is a partial solution. We find that C' ^ 
3/7'. (C A D A{a A ai ^ t')) where IF = fv{Fx,C\ a\ F). From 4 we have 
that C A D ^ T 2 A a). We conclude that C" ^ 3/7'. (ai = ti). We 

maintain that every solution to cxi in C' must consist of t\. 

Starting from C' ,Fx.x : a\ b e : r' we can derive (by application of the Sub- 
titution Lemma) [t\/ ai\C' ,Fx b Xx.e : t\ [Ti/ai]r'. Note that the constraint 
[ti/q:i]C" is satisfiable. (C, a) is a partial solution. We hnd that [Ti/ai\C' ^ 
3/7". (7 AD A{aAT\ ^ [ri/aijr') where /7" = fv{Fx, \Tiai]C' ,t\ — > [ri/ai]r'). 
We can conclude that [ri/ai]/7' \= 3/7.(/7A(ti T2 A a) AD A{t2 A [n/aijr')) 
where U = fv{Fx.x : ai,/7',r'). Note that [ri/ai]/7' 3U.{C A (n ^ T 2 A 

a) A D A {t 2 A [n/aijr')) iff C' 3/7.(/7 A (ai — > 02 A a) A (ai = ti) A (u 2 = 
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T2)ADA {a2 At')) because every solution to ai in C" must consist of ti, i.e. for 
every r{ we have that [r(/ai]C" ^ [[f /aJri/aiJC" for some types r and type 
variables a. We established the left part of the iff therefore the right part holds 
as well, i.e. we can establish part ( 3 ) in the definition of partial solutions. This 
concludes the correctness proof for rule (Abs-Af). 

In case of rule (App-Af) we find the following situation: 

C', r, ei : ai Di C = C A (oi <a2^oi) C , F, 62 : a'2 ^2 

C" — Di A {a'2 A C(2) ai,a2,a2 new 
C,r,ei62 : a D2 

By assumption (C,a) G PartSol{r, 6162) ■ First, we show that {C A (ai ^ 
«2 ^ Oi),ai) G PartSol{r, ei | P, 6162). 

We assume we are given C',P h ei : r'. The context information enforces 
that we have the following (normalized) derivation 

C', A h ei : A C',r A 62 ■■ C' h jr' A t[ ^ r^) 

C', r h 6162 : T2 

(C,a) is a partial solution. We find that C' \= 3U'.{C A D A {a A 72)) where 
U' = fv{r,C',T2). This ensures that C" A C is satisfiable. Weakening yields 
C' A C,r h d : t'. From that we obtain C A {a\ A a2 ^ a) A C' A {a\ = 
t') a (o2 = r{) A {a A T2),P F Ci : ai which establishes part ( 2 ). 

Part ( 3 ) follows straightforwardly. We have that 

C' 1 = 3U.{C A {ai Aa2 ^ a) AC' A (ai = t') A (02 = r() A (a ^ r^) A (ai ^ A)) 

where U = /^(F, C", r'). 

It remains to prove that {Di A (a'2 A 0:2), G PartSol{P, 62 |F, 6162). We 
assume we are given C' , P F 62 ■ t{. The context information enforces that we 
have the following (normalized) derivation 

C', P A ei-.T' C',P A 62 ■■ C' h (t' ^ ^ r^) 

C', P F 6162 : T2 

Then, we can derive that FiA(a2 ^ a2)AC' A(a'2 = t[),P F e : By induction 

we assume that all inference nodes above preserve partial solutions. Hence, we 
can apply the inference result (completeness) and obtain C' \= 3P.{Di A (ai A 
t')). Finally, we can conclude that C' ^ 3U.(P)i A (a'2 A 02) A C' A (a'2 = 
t[) a (a'2 At'i)) where U = fv(P, C ,t[) and we are done. 
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Abstract. Many modern programming languages use garbage collection for the 
sake of reliability and productivity. On the other hand, garbage collection causes 
several difficulties in some situations, for example, in real-time systems. 

Tofte and Talpin’s region and effect system for ML infers lifetime of objects 
at compile time and makes it possible to reclaim memory safely without using 
garbage collectors at run time. Programmers do not have to provide any explicit 
directives about lifetime of objects. However, it is sometimes necessary for pro- 
grammers to transform programs specially in order to make the system infer as 
they intend. As a result, programmers have to know, to some extent, how the 
system infers about regions. 

In this paper, we introduce a type system for an ML-like language which also 
aims for compile-time lifetime inference. It, however, lets programmers delimit 
lifetime of objects explicitly and makes the system check the correctness of pro- 
grammers’ directives. 



1 Introduction 

Most functional languages such as ML and Haskell, and many object-oriented lan- 
guages such as Smalltalk and Java use garbage collection to reclaim memory auto- 
matically. Programmers are freed from worry about memory management and they can 
enjoy more safety and productivity than in conventional languages such as C. On the 
other hand, garbage collection causes several difficulties in real-time systems and very 
small systems, since it is difficult for us to predict execution time of particular parts of 
programs and since garbage collection requires certain amount of memory in order to 
be performed efficiently. 

Tofte and Talpin’s region and effect system for ML [8] is an alternative to run-time 
garbage collection. It infers lifetime of objects at compile time and makes it possible to 
reclaim memory safely without using garbage collectors at run time. Then, objects can 
be allocated in a stack (to be exact, in a stack of regions). The system uses an ordinary 
ML program as input, and annotates it with region operators such as letregion and 
at. Here, “letregion p in e” is a computation which allocates a new region p on 
top of the stack, computes e and then deallocates p, and “e at p” means that the result 
of e is allocated in region p. Programmers do not have to provide any explicit direc- 
tives about lifetime of objects. It is sometimes necessary, however, for programmers to 
transform programs specially in order to make the system infer as they want. Therefore, 
programmers have to know, to some extent, how the system infers about regions. 

The following example is reported in [7]. 

H. Kuchen and K. Ueda (Eds.): FLOPS 2001, LNCS 2024, pp. 264-279, 2001. 

© Springer-Verlag Berlin Heidelberg 2001 
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(* A *) 

fun length ( [] , acc) = acc 

I length (_: :xs, acc) = length (xs, acc+1) 

(* B *) 

fun length 1 = 

let fun loop (p as ( [] , acc) ) = p 

I loop (_: :xs, acc) = loop (xs, acc+1) 

in snd (loop (1, 0) ) end 

If we define length as A *) , contrary to programmers’ intention, every time 

length is called recursively, a new tuple for the argument is allocated in a new region. 
The stack size becomes proportional to the length of the list. On the other hand, in 
length (* B , a new region is not created for each recursive call thanks to “as” 
pattern in the second line. And a further analysis called storage mode analysis detects 
that even in-place updating of the tuple is possible. As a result, length (* B *) 
can be computed in a constant size of memory. 

Instead of a system which infers all about regions automatically, it might be con- 
venient to have a semi-automatic system which lets programmers delimit lifetime of 
objects explicitly and checks safety of such directives. This is what we want to propose 
here. In principle, such an explicit style would be possible in Tofte and Talpin’s system 
by just allowing programmers to use region annotations explicitly. In practice, however, 
it would be difficult to do so, since region annotations tend to be lengthy and complex. 

For example, the following program: 

(let X = (2, 3) in Ay. (fst x, y) end) 5 
is region-annotated by Tofte and Talpin’s system as follows [8]: 

letregion p 4 , 

in letregion pe 

in let X = (2 at /92/ 3 at pe) at p 4 
in (Ay. (fst x, y) at pi) at p^ 

end 

end 

5 at p 3 

end 

There are too many annotations (letregion and at) about regions to be used explic- 
itly by programmers. Moreover, type expressions may be also lengthy and complex. 

On the other hand, Launchbury and Peyton Jones proposed a special construct 
runST [4] for Haskell, which encapsulates stateful computations in pure computa- 
tions. “State” in Launchbury and Peyton Jones’s terminology corresponds to “region” 
in Tofte and Talpin’s. Semmelroth and Sabry [5] studied and formalized the connection 
between Launchbury and Peyton Jones’s monadic state encapsulation and the region 
and effect system. They showed that monadic operators and runST can be used as “a 
cheap form of” region and effect system, that is, they can be used in order to delimit 
lifetime of objects in call-by-value functional languages. It is “cheap” because it can 
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handle only a single region at a time and cannot handle stacks of regions like Tofte and 
Talpin’s. 

The system which will be proposed in this paper extends the system of monadic 
encapsulation of Semmelroth and Sabry. In addition to runST, which simply encap- 
sulates the state, it provides an operator which extends the current state with a new 
region and makes a stack of regions. In most cases, programmers do not have to spec- 
ify regions. Then, the current default region which is passed around implicitly is used. 
However, sometimes programmers want to access older regions instead of the current 
newest region. In such cases, programmers are able to explicitly specify the region. 
Compositional references, which the author proposed in [2] in order to manipulate gen- 
eral mutable data structures in Haskell, are used for this purpose. Our region actually 
corresponds to a set of regions of Tofte and Talpin’s. A newer region contains older 
regions and there is a kind of a subtyping relation between old and new regions, which 
is helpful to keep type expressions simple. When our region primitive named letex- 
tend allocates a new region and makes it the default region, it passes to the inner 
expression a reference to the old default region. This is contrary to Tofte and Talpin’s 
letregion, which passes to the expression a reference to the newly created region. 

We do not discuss issues such as dynamic semantics and type safety of the proposed 
extension in this paper. Instead, we will mainly focus on type inference. One of the 
important points of Tofte and Talpin’s system is type inference of recursive functions. 
Recursive functions must be given region polymorphic types in order for the system to 
be practical. In general, however, ML-style type inference algorithm cannot infer the 
most general type for polymorphic recursion. Tofte and Talpin’s system treats region 
parameters in a special way to deal with polymorphic recursion. However, since our 
system treats regions explicitly and shows information about regions to programmers 
as a part of type expressions, it is not natural to treat regions specially in type inference. 
Therefore, in our system, regions and effects are not distinguished from ordinary type 
parameters in type inference of recursive functions. We will present another way of 
inferring types of recursive functions when polymorphic recursion is necessary. 



2 Our Language 



In this section, we present our language which is basically a variant of EML (Encap- 
sulated ML) of Semmelroth and Sabry [5]. We, however, choose a simpler form. For 
example, let-binding is restricted to values. 

Our language is a call-by-value functional language and its syntax and type system 
are shown in Figure 1. Here, an overline {e.g. a) is a sequence of something, FV(t) 
means /ree variables of r as usual and a y t means “cr instantiates to r.” 

In these rules, the type expression after “!” is the effect of the expression. We use 
a notational convention here that if an expression does not have any effects, this effect 
is written as underscore (_) (as in (Var) and (Lambda) rules and in the premise of (Let) 
rule) meaning a fresh variable. This convention is analogous to the use of underscore 
in pattern matching in many functional languages. We will refer to the typing rule for 
recursive definitions (LetRec) later. 
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V G Value 
X £ Id 


V 


X 


\\x ^ e 


e G Expr 


e 


::= 6 1 6 6* 1 let x = e in e' \ encap e 

1 letrec 2 ; = e in e' | letextend 2 ; in e | e at e 


m G Effect 


m 


a 


ST T 


T G Type 
O' G TypeVar 


T 


::= a 


1 T > T 1 Ta T T 


7T G TypeWithEff 


7T 


::= T ! 


! m 


(X G TypeScheme 


(7 


::= T 


Va. T 



X :: a e r o-yr F \~ ei :: (ti — > T2) I m T h 62 :: ri ! m 

(Var) ^ (App) 



_r h 2 ; :: r ! . 
r, X ~ Ti \- e ~ T2 \ m 



_r h ei 62 :: T2 ! m 



(Lambda) 



_T h Aa; 6 :: (ri — > T2) ! _ 

_T h 6 i :: Ti ! _ (ei : value) F, x :: Va. ti h 62 :: T 2 ! m (a = FV{t) \ FV{F)) 
F h let 2 ; = 6 i in 62 :: T 2 ! m 

r h 6 :: r ! ST s s 0 FV{F) U FV{t) 



(Let) 



F h encap e :: r ! . 



(Encap) 



Fig. 1. Typing Rules 



(Encap) explains the encapsulation construct which corresponds to Launchbury and 
Peyton Jones’s runST. Usually, encap is used with the primitive operators on ML- 
style references: 

ref :: r — Ref s r 

, £ „ £ ST s 

deref :: Ref s r — r 

ST s 

setref :: Ref s r — y r — y Unit 

In this paper, however, in-place updating is not a main topic and we introduce other 
primitives later. It would be straightforward to add in-place updating to our proposal, 
though. 

As a generalization of encap, we introduce a new operator letextend which 
also has a special typing rule: 

U, 2; :: Ta s f h e :: r ! ST s s ^ FV(F) U FV(t ! ST f ) 

^ i (Letextend) 

F h letextend 2; in e :: r ! ST f 

A condition similar to encap should hold for s and r. Intuitively, s is a region which 
extends a region f. In letextend x in e, though e is computed using the region s, 
s is not visible from outside and the expression behaves as a computation on the region 
t . Objects allocated in s \ t become unnecessary and get reclaimed when the execution 
of letextend x in e is finished. 
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For example, 

letextend x in var a = newArray n 0 in 
foo a 

An array a is allocated in the new region created by letextend (new objects are 
allocated in the newest region by default), used in foo and is reclaimed after the eval- 
uation of letextend ... is finished. (Here, we use var t; = ei in 62 as a shorthand 
for (At; — ;> 62 ) ei. Since let is restricted to values in our language, we cannot write 
let t; = 6i in 62 when ei is a computation.) 

Though X is not used in the example above, it is bound to a reference to old region 
which was active just before letregion ... is executed. Ta is the type constructor for 
compositional references. Compositional references are abstract data which represent 
(the position of) an inner object relative to some base object. If the type of the inner 
object is t and the type of the base object is s, the type of the compositional reference 
is Ta s t. (Ta s t reads “t at region s.” Ta s f is written as Mut s t in [2], We use a new 
name Ta, since it seems Mut(able) is not an appropriate name here — it is only used in 
order to associate objects with regions.) 

At a glance, letextend resembles Tofte and Talpin’s letregion, however, 
note that the value given to the variable of letextend (e.g. x in the above example) 
points to the old region instead of the new region. 

Another new primitive for compositional references is at: 

T h ei :: Ta s f ! ST s T h 62 :: r ! ST f 

("At') 

T h 62 at ei :: r ! ST s 

“62 at 61” intuitively means that 62 is computed in the region whose position is given 
by 61. Though we use the same name as Tofte and Talpin’s operator, its meaning is 
slightly different. Our at may be used even when 62 is not a constructor application as 
is shown soon later. The construct at corresponds to appR in [2]. We use at when we 
want to take r ! ST f — an expression using region t as r ! ST s — an expression using 
region s where s is bigger than t . See [2] for details. Later, we will introduce a simple 
form of subtyping, in order to do without using at explicitly in most cases. 

We give primitive functions for pairs and lists as follows. 



mkPair 


:: a — 


h 


S rr, 

1 Ta 
ST 


s (a, 
s 


b) 


f St 


~ Ta s 


(a, h) 


ST 


>■ a 
s , 




snd 


:: Ta s 


{a, b) 


^ h 




nil 


:: Unit 


ST s „ 

— 7> Ta s 


(List 


s a) 


cons 


:: a 


Ta s 


(List s a) 


ST 


isNull 


:: Ta s 


(List 


s a) 




Bool 


head 


:: Ta s 


(List 


s a) 


ST 


a 


tail 


:: Ta s 


(List 


s a) 


ST 


Ta s 



(List s a) 
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Ta s (List s a) is the type of lists allocated in region s. Since List is a re- 
cursive type constructor, List must have a region parameter s as one of its parameters. 
The following is the declaration of List written in the notation of Haskell. 

data List s a = Cons a (Ta s (List s a) ) | Nil 

When we are computing on region s and a list is in region t where s includes t, we have 
to use a compositional reference and at to access the list as follows. 

var xs = cons 1 (nil ()) in 

letextend t in var x = head xs at f in ... 



However, we will soon find that using at in this way is tedious and makes programs 
clumsy. Therefore, we introduce a kind of subtyping as follows. 



cons 

isNull 

head 

tail 



s Z) t ^ a 
s Z) t ^ Ta t 
s T) t ^ Ta t 
s T) t ^ Ta t 



Ta t (List t a) 

(List t a) — ;> 

^ ST s 
(List t a) — ;> 

(List t a) — ;> 



qT s 

— Ta t (List t a) 

Bool 

a 

Ta s (List s a) 



f St 

snd 



ST s 

~ s T) t ^ Ta t {a, b) — a 

qm c 

~ s Z) t ^ Ta t {a, b) — y b 



Here, s D f is a type constraint which means s is an extension of t . Then, at is inserted 
automatically where the constraint s D f is used. Explicit use of at is rarely necessary. 
The type of letextend is changed accordingly. 



r, X ~ Ta s t \- e ~ P ^ T \ ST s s ^ FV{P) U FV{P' ^ r ! ST f) 

{sT)t} P P' h P 

P h letextend x Ln. e P' ^ t \ ST t 

Here, If is the standard entailment relation for subtyping constraints consisting of re- 
flectivity and transitivity rules. 

TreH P ¥ sT)t P ¥ tT)u 

P ¥ t: P¥sZ)s P¥sZ)u 

The typing rules for the other constructs are also changed straightforwardly in order to 
carry over type constraints. 



3 Recursive F unctions and letextend 

Since letextend requires one of region parameters to be polymorphic, it is impossi- 
ble for the ordinary ML-style type inference algorithm to infer the type of a recursive 
function which calls itself inside letextend. 

It is well-known that type checking, instead of type inference, is possible even for 
polymorphic recursion as in the following rule. 
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r, X :: Va. P\^ ti\~ ei :: _Pi ^ ri ! _ P, x :: Ma. Pi^ ti\~ P 2 ^ \ m 



P h letrec * = ei in P 2 ^ \ m 

(Here, we restrict ei to values.) 



(LetRec) 



However, it would be a burden for programmers to explicitly give a type to every re- 
cursive function. It would be better if we could define recursive functions which use 
letextend without supplying their types explicitly. 

Tofte and Birkedal’s type inference algorithm [6] for polymorphic recursion 
(letrec * = ei in e^) is summarized as follows. 



- First, we infer the type of ei ignoring region parameters. 

- Next, we give it the most general region type. That is, we use a fresh region variable 
everywhere a region parameter is required. Assuming that x has this very general 
type, we infer the type of ei again. If the type of x and the type of ei are identical, 
type inference is finished. 

- If they are not identical, we assume that x has now the new type of ei and process 
ei again. And repeat this until the types of x and ei agree. 

They proved that this iteration always terminates in their system. 

This proof, however, depends on the properties characteristic to their system. Since, 
in their system, effects and regions are used only internally in the compiler, this ap- 
proach seems feasible. However, in our system, effects and regions are explicit and they 
are shown to programmers as part of type expressions. It seems unnatural to treat region 
parameters specially in type inference. 

Instead, we take another approach to type inference of recursive functions 
(letrec * = ei in 62 ), which is roughly summarized as follows: 

- When we check the condition of encap (s ^ FV{P) U FV{t)) and letextend 
(s ^ FV{P) U FV{t ! ST t)) in ei, we do not take into account occurrences of the 
type variable s in the type of the letrec-bound variable x in the environment P. 
Instead, we just keep track of such occurrences. Such occurrences do not do harm, 
if later it is found that they can be replaced with a more generic type. 

- When we unify the type of ei and x, we check whether the positions of the occur- 
rences recorded in the above process can be made generic. We also check encap 
and letextend in ei again so that the region variable (s) to be confined does not 
appear free in the type environment (P) or the type of the result (r). 

That is, we postpone the check of the special condition of encap and letextend 
until the check of enclosing letrec’s. It is an ad-hoc extension of the usual ML- 
style type inference. However, it seems to work and is sufficient for our purpose. Our 
type inference algorithm TC is shown in Figure 2, 3 and 4. Letrec-bound variables are 
written as * :.r t and are distinguished from other variables written as * r in the 
environment. Figure 5 shows auxiliary functions used in Figure 3 and 4. 

The soundness of this algorithm with respect to the type system (h) is shown by 
considering another type system (!-')■ See the appendix (Section A) for the definition of 
h' and part of the proof of the soundness of TC. 
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TC takes an environment F and an expression e, and returns a triple of a substitu- 
tion, a type expression and the third component that is explained soon later. Figure 2 
shows type inference for variables, applications, A-abstractions and let-expressions, 
which does not differ so much from ordinary type inference algorithm for ML except 
the third component of return values. Figure 3 explains type inference for encap and 
letextend. In type-checking encap and letextend, the region part of the type 
expression is assigned an expression k[t\ — k is a fresh special type constructor, and 
r is a parameter representing its direct subregion {i.e., k[t] D r holds). For technical 
reason, we define FV(k[t\) = 0 whatever the type expression r is. This special con- 
structor indicates that it must become generic type variable later. This is very similar to 
the use of skolem constructors in the theory of existential types [3]. FS(t) means a set 
of such special constructors occurring in r and FSV{t) is defined as FS{t) U FV(t). 
Furthermore, we keep track of free variables of the environment and the type in the third 
component (/) of the result of TC when type-checking encap and letextend. (Here 
I ranges over sets of pairs of a special constructor and a set of (free) variables and spe- 
cial constructors.) This is necessary because otherwise later in type-checking letrec, 
it is possible that such free variables be unified with type expressions containing k. The 
type checking rule for letrec ensures that this does not happen. 



In type-checking encap and letextend, if there exists some variable a such that 
a D k[t] e UP, such a should be checked in the same way as k[t\ so that it does not 
escape, though in order to keep the presentation simple, we do not make this explicit in 
the rules. 



Figure 4 shows type inference for letrec-expression. First, we begin with replac- 
ing each occurrence of x with fresh variables {xi}, for due to polymorphic recursion 
they might be instantiated to different types. Then x^s are assigned types Sai which 
may contain special constructors. Before performing unification, we replace each occur- 
rence of such special constructors (along with their parameters) in Sai with a fresh type 
variable and obtain ctj-. Let U be the most general unifier of Ci and r. Since Uci = Ut 
by definition of U, U Sai and U r are almost the same except special constructors in 
Sai. Zi maps variables in Lr to special constructors in Sai. Moreover, if there are 
variables in Sai that are unified with new variables in cr, , they should also be mapped 
to special constructors. This mapping is done by Y. Y must be consistently defined for 
all i and should not affect variables in FV{U S'Y|jv) U FV{U r). 



Note that Zi and therefore Y, are not substitutions in the usual sense, since they 
are not idempotent, that is, Zi maps a variable t; to a type expression containing v itself 
(e.g. k[i^]). The condition Vi. liom(Yj ) C FV{U r) \FV{YU SP) means that special con- 
structors that appear in the environment are actually thought of as instances of generic 
types. OK(AddVar((YL * /), cr)) checks whether the condition of encap and le- 
textend holds still true. The condition ZiV Z)v is necessary because otherwise the 
number of subtyping constraints of the type of the letrec-expression might increase 
in an unexpectahle way due to polymorphic recursion. 
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TC( r, x ) = 

if a; Va.P ^ r G -T (-C can be either n or r) then (/d, (P ^ r ! _)[t/a], 0) (t : fresh) 
TC{r, e e') = 

let (5, P T \ m, I) = TC{r, e) 

(S', P' \ m', /') = TC(SP, e') 
fj. and (3 are new type variables. 

U = mgu{{S’T,T’ 13}) 

U' = mgu({U s' m, U m' , jj}) ■ U 
in (U'S'S, U'(S'P UP' ^j3\n),U' i. ((5' ★ /) U /')) 

TC{P, \x^e) = 
let /? is a new type variable. 

(S, P ^ T \ m,I) = TC(P + {x /?}, e) 
in (S, P^ S/3 ^ /) 

TC(P, let a; = e in e*) = 
let (S,P^t\.,I) = TC(P, e) 

(s' , P' ^ t' \ m, /') = TC(SP + {x ~n gen(Sr, P ^ r)}, e') 
in [s' S, P' =S t' \ m, (S' -k I) U l') 



Fig. 2. Type Inference Algorithm (Part 1) 
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TC(r, encap e) = 
let (S, P T \ m, I) = TC{r, e) 

U = mgu({r ! m, a ! ST {K[Uni t])}) 

(k is a new special constructor, and a is a new type variable.) 

P' = Simplify) t/ P, {K[Uni t] D Uni t}) 
if K ^ FS{P' ^Ua)UFS{USr\j^) 
then {US, P' a \ S), 

(t/ ★ /) U {(k, FSV{P' ^ Ua) U E5R(t/5r|^))}) 

TC{r, letextenda; ine) = 

let {S, P T \ m, P) = TC{P + {x :: Ta t}, e) 

U = mgu{{r ! m,a ! ST 

{k is a new special constructor, a and t are new type variables.) 
P' = Simplify(t/ P, {U (fi:[t]) DUt}) 

T = P' ^U{a 1 st t) in 
if K ^ FS{t) U FS{USP\p^) 
then (US, T, (U * I)U{{n,FSV{T)UFSV{USry))}) 



Fig. 3. Type Inference Algorithm (Part 2) 
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TC{r, letrec a; = e in e*) = 

let e* is an expression obtained by replacing each occurrence of a; in e 
by a new variable x,. (i.e. e = e*[x/ xi\) 

{s,q^t \ .,1) = Tc(r + ur=i{^' 

where a, is a new type variable. 

cr, is a type expression obtained by replacing each occurrence of 
applications of special constructors in Sa, with a new variable. 
i.e. 3 Bf B,/t, = Sot 
U = {(T,} U {r}) 

Z, is a substitution s.t. Z,U = B, on dom(B,) 

Y. = Z.\FV(usa,) and Y = 

(Yi ’s must be all disjoint. Also note that YU Sa, = Z,Ut) 
a = gen{YUSr,U{Q ^ t)) in 
if 'ii.dom(Z,) C FV(Ut) \ FV(YUSr) 
and dom{Y) C\ {FV{U Sr\N) 'S FV{Ut)) = % 
and OK(AddVar((yt/ ★ /), cr)) and Si.Sv dom{Z,). Z,vZ)v 
then let (S' , t' , l') = TC(YU SF + {x a}, e') in 
(S'YUS, t', s' ★ (AddVar(yt/ ★ I, (t)) U /') 

Fig. 4. Type Inference Algorithm (Part 3) 



Y\r = ■■r T I (x ~r t) G F} 

F\pf = {x T I (x t) G F} 
gen{F, t) = V(FV(r) \ FV(F)).t 

S * I = {(k, {n I t G Vi, n G FSV(S t)}) | (k, m) G /} 

AddVar(/, a) = {(k, ss U FSV(a)) \ (n, ss) G /} 

0K(/) = V(k, m) £ F k ^ ss 
Simplify(P, Q) = if n[s]Dt E Q and n[s]Da E P 

then Simplify((P \ {k[s] Da}) U {Oa}, Q) else P 



Fig. 5. Auxiliary Functions 
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4 Examples 



In this section, we show examples type-checked by the above algorithm. All the exam- 
ples are taken from [7] and are translated to our language straightforwardly. 

First, we show the dehnition of msort (merge sort) function (Figure 6). As we do 
not use pattern matching here, the definition becomes a little lengthy. However, except 
the use of letextend and at (and hence copyD function), this is a straightforward 
(and maybe naive) implementation of merge sort algorithm. 

We use letextend and at as follows. When we split list in msort by calling 
split, we put the two lists obtained as the result in the extended part of the region 
created by letextend, since they only have to survive during the recursive call of 
msort. The function copyD which is called from merge uses at explicitly to allocate 
a new list in the old region. This is necessary because the return value of merge in the 
dehnition of msort must be used outside the surrounding letextend. 



split xs 1 r = if isNull xs then mkPair 1 r 

else if isNull (tail xs) then 
mkPair (cons (head xs) 1) r 
else split (tail (tail xs) ) (cons (head xs) 1) 
(cons (head (tail xs) ) r) 

copyD t xs = if isNull xs then (nil ()) at t 
else var a = head xs in 

var as = copyD t (tail xs) in cons a as 

merge t xsO ysO = if isNull xsO then copyD t ysO 

else if isNull ysO then copyD t xsO 
else var y = head ysO in 
var X = head xsO in 

if x<y then 

var xsl = merge t (tail xsO) ysO in 
cons X xsl 

else 

var ysl = merge t xsO (tail ysO) in 
cons y ysl 

msort xsO = if isNull xsO then nil () 

else if isNull (tail xsO) then xsO 
else letextend t in 

var p = split xsO (nil ()) (nil ()) in 
var 1 = fst p in var r = snd p in 
var 11 = msort 1 in var rl = msort r in 
merge t 11 rl 



Fig. 6 . The definitions of split, merge and msort 
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The types of these functions are inferred as follows: 



split :: s D f ^ Ta f (List t a) 

ST s ST s 

— ^ Ta s (List s a) — ^ Ta s (List s a) 

ST s 

— ^ Ta s (Ta s (List s a) , Ta s (List s a) ) 
ST s 

merge :: s D t ^ Ta s ^ ^ Ta s (List s a) 

S T 5 ST 5 

— Ta s (List s a) — Ta t (List t a) 

ST s 

msort :: Ta s (List s a) — Ta s (List s a) 



The second example is a version of Eratosthenes’s sieves using lists (Figure 7). The 



sift n xs = if isNull xs then nil () 

else var y = head xs in var ys = tail xs in 
if mod n y == 0 then sift n ys 
else cons y (sift n ys) 

sieve xs p = if isNull xs then p 
else letextend t in 

var z = head xs in var zs = tail xs in 
var rest = sift z zs in 
sieve rest (cons z p) 



Fig. 7. Eratosthenes 



intermediate list rest is allocated in the new region created by letextend. The type 
of sieve is inferred as follows. 

ST s 

sieve :: s D f ^ Ta s (List s Int) — ?> Ta t (List t Int) 
ST s 

— y Ta t (List t Int) 

Both examples show that it is relatively easy to insert letextend at appropriate 
places, and that the output produced by the type inference algorithm is readable. 

In Tofte and Talpin’s system, a further optimization called region resetting [1] is 
inserted by storage mode analysis. Then sieve above can be executed with a single 
region. In our system, no operator that corresponds to region resetting is offered. Any- 
how, it is obvious that if we use destructive update and iteration instead of recursion, 
the above two examples can be made more space efficient. Nonetheless, it does not 
mean that our attempt is meaningless. Since recursive and non-destructive definition 
is easier to write in general, it would be often the case that first we define a recursive 
and non-destructive version of an algorithm and then gradually rewrite it into a more 
space-efficient version. 
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5 Concluding Remarks 

We presented a type system where programmers can give explicit directives about life- 
time of objects. Regions are hierarchical and are given a kind of subtyping relations 
between them. This fact simplifies representation of regions. We explained type infer- 
ence of recursive functions and showed the results for some short examples. Composi- 
tional references play an implicit role in our system. They are actually used when we 
use subtyping of the form sZ)t. 

We should remark that, in this paper, allocation of function closures is disregarded 
and that partial function application such as map f is not used. Creating a function 
closure might actually consumes memory. Therefore, it might be necessary that the 
type constructor — ;> also be associated with Ta s. Then, if we define a curried function 
(e.g. map) and give it a full number of actual arguments (e.g. map f xs), at least 
conceptually, closures for intermediate partial applications (e.g. map f) are created 
and used immediately. Intuitively, however, full function applications do not consume 
the heap nor the regions for intermediate closures. It seems that this sort of memory 
reclamation can not be expressed as a typing rule like the one presented in this paper. 
However, it should be noted that our main objective in this paper is to simplify the 
representation of regions. Then, associating regions to even such short-lived closures 
seems incompatible to our approach. There would be several workarounds however, for 
example, to separate partial and full function applications syntactically and to associate 
regions only to such explicit partial applications. 

It is necessary to prove that our new operator letextend can safely deallocate 
the extended region. Semmelroth and Sabry [5] defined dynamic semantics and proved 
subject reduction property for a language which includes runST. The author believes 
that their technique can be extended to our language which includes letextend. 
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A Soundness of TC 



In this section, we will prove the soundness of TC with respect to h. Of course, the 
completeness cannot be proved, since h permits polymorphic recursion (LetRec). 

First, we need a new form of typing rules (h') which bridges the gap between TC 
and (h). 

Definition 1. 



X ::(n0Rr) (T C r cry P 
r h' * ^ r ! _, 0 



(Var’) 



r, X T\ \-' e t P => T2 \ m, I 
P \-' \x ^ e P ^ Ti T2 ! _, / 



(Lambda’) 



P \-' ei :: Pi n \m,Ii P \~' 62 :: P2 ^ n \ m, h 

P h' ei 62 :: Pi U 7^2 ^ ''"2 ! rn, Ii U I2 



P h' 61 :: Pi ^ Ti ! 7 i 

P, X Va. Pi ^ Ti h' 62 :: P2 ^ T2 ! m, I2 (a = FV{ti) \ FV{P)) 
P h' let * = 61 in 62 :: P2 => T2 \ m, 7 i U I2 



P, X Va. Pi ^ ri h' 61 :: Pi ^ n ! 7 i 

P, X Va. Pi ^ n , h' 62 :: P2 ^ T2 ! m, I2 (a = FV(ti) \ FV(P)) 

P h' letrec * = 61 in 62 :: P2 ^ T2 ! m, 7 i U I2 



(LetRec’) 



P h' 6 :: P ^ r ! ST{K[Unit]), I 

P' = Simplify(P, t] D Uni t}) k ^ FS{P' ^ r ! m) U FS{P\jyf) 

P h' encap e t P' ^ t \ m, I' 

(P = 7 U {{ti,FSV{P' ^ r ! m) U FSV{P\j^))}) 

(Encap’) 



P, X :.n Ta (k[/]) / h' 6 :: P ^ r ! ST(k[/]), 7 
P' = Simplify(P, {«[/] D/}) K ^ FS{P' r ! STt) U FS{P\j\f) 
P h' letextend * in 6 P' ^ t \ STt , 7 ' 

(P = 7 U {(K,P 5 V(P'^r ! STt)UFSV{P\j^))}) 



(Letextend’) 
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Note that, if _T h' e :: _P ^ r, / and F\r = 0, then _T h e ~ P holds. For h', we can 
prove some desirable properties. 

Lemma 1. If P \~' e ~ P ^ t, I and 0K(5 * I), then SP h' e :: S(P ^ t),S -k I. 

Proof. By induction on the structure of the derivation. 

Lemma 2. If^,\J^{xi Ti} \-' e z P ^ T, I and\/i. a y Ti 

and 0K(AddVar(7, cr)) then P, x cr h' e[x/xi] z. P ^ t, AddVar(7, cr). 

Proof. By induction on the structure of the derivation. 

Lemma 3. ( Soundness ofTC) 

IfTC{P, e) = (S, T, I), then SP h' e z r, 7. 

Proof. We show the case of (LetRec). 

Let (5*, T* , I*) = TC{P, letrec x = e in e'). By the dehnition of TC, there 
exists S,Ti, I s.t. 

{S, Q ^ n ! _, 7) = TC{P + Ur=i{*i - ai}, e*) 

where e* is an expression as is dehned in the algorithm. By induction, 

Sr + ur=i{*» - Sai} h' e* zQ^n\_,I 

By lemma 1, 

YL5L + Ur=i{*i Y YUSai} h' e* :: U{Q^ti \_),YUkI 

By the condition Vi. Vu £ dom{Zi). ZiV D v, adding constraints ZiUQ to the type 
of Xi does not actually add new constraints to the type of e* because they are hnally 
simplified to UQ. 

YUSP + \J"^^{xi Zr ZiUQ^YUSai] h' e* :: U{Q^ti \_),YUkI 
By the dehnition of Y, YU Sai = ZiUci = ZiUri. Then, by lemma 2, 

YU SP + {x Zn cr} e z. U {Q ^ Ti \ _) , AddVar(Y17 -k I, a) 

By the dehnition of TC, there exists S' ,t' , I' s.t. 

[S', t', I') = TC{YUSP + {x Zn <t}, e') 

By induction, 

S'{YUSPp{x Zn (t}) h' eJ z. t',I' 

Moreover, by lemma 1 , 

S'{YUSP + {x Zn (t}) K e zS'U{Q^ti ! _) , 5' * (AddVar(Y Y * 7, (t)) 

By (LetRec’), 

S'YU SP h' letrec * = e in e' :: r', S' k (AddVar(Y Y k 7, cr)) U I' 
where 5* = S'YUS, t* = t' and I* = S' k (AddVar(YY * 7, cr)) U I'. 
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Abstract. We consider prescriptive type systems for logic programs (as 
in Godel or Mercury). In such systems, the typing is static, but it guar- 
antees an operational property: if a program is “well-typed”, then all 
derivations starting in a “well-typed” query are again “well-typed” . This 
property has been called subject reduction. We show that this property 
can also be phrased as a property of the proof-theoretic semantics of 
logic programs, thus abstracting from the usual operational (top-down) 
semantics. This proof-theoretic view leads us to questioning a condition 
which is usually considered necessary for subject reduction, namely the 
head condition. It states that the head of each clause must have a type 
which is a variant (and not a proper instance) of the declared type. We 
provide a more general condition, thus reestablishing a certain symmetry 
between heads and body atoms. The condition ensures that in a deriva- 
tion, the types of two unified terms are themselves unifiable. We discuss 
possible implications of this result. We also discuss the relationship be- 
tween the head condition and polymorphic recursion, a concept known 
in functional programming. 



1 Introduction 

Prescriptive types are used in logic programming (and other paradigms) to re- 
strict the underlying syntax so that only “meaningful” expressions are allowed. 
This allows for many programming errors to be detected by the compiler. More- 
over, it ensures that once a program has passed the compiler, the types of argu- 
ments of predicates can be ignored at runtime, since it is guaranteed that they 
will be of correct type. This has been turned into the famous slogan [19,20] 

Well-typed programs cannot go wrong. 

Adopting the terminology from the theory of the A-calculus [29], this property 
of a typed program is called subject reduction. For the simply typed A-calculus, 
subject reduction states that the type of a A-term is invariant under reduction. 
Translated to logic programming, this means that resolving a “well-typed” query 
with a “well-typed” clause will always result in a “well-typed” query, and so the 
successive queries obtained during a derivation are all “well-typed” . 

From this observation, it is clear that subject reduction is a property of the 
operational semantics of a logic program, i.e., SLD resolution [17]. In this paper, 

H. Kuchen and K. Ueda (Eds.): FLOPS 2001, LNCS 2024, pp. 280-295, 2001. 
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we show that it is also a property of the proof-theoretic semantics based on 
derivation trees. This is obtained by showing that using “well-typed” clauses, 
only “well-typed” derivation trees can be constructed, giving rise to the new 
slogan: 

Well-typed programs are not wrong. 

The head eondition, which is a condition on the program (clauses) [13], is usu- 
ally considered to be crucial for subject reduction. The second objective of this 
paper is to analyse the head condition in this new light and open the field for 
generalisations, of which we introduce one. 

The head condition, also called definitional generieity [16], states that the 
types of the arguments of a clause head must be a variant^ (and not a proper 
instance) of the declared type of the head predicate. This condition imposes 
a distinction between “definitional” occurrences (clause heads) and “applied” 
occurrences (body atoms) of a predicate. In contrast, the proof-theoretic view 
of subject reduction we propose reestablishes a certain symmetry between the 
different occurrences. By this generalisation, the class of programs for which 
subject reduction is guaranteed is enlarged. 

This paper is organised as follows. Section 2 contains some preliminaries. Sec- 
tion 3 introduces our proof-theoretic notion of subject reduction. Section 4 gives 
conditions for subject reduction, and in particular, a generalisation of the head 
condition. In Section 5, we discuss, in the light of these results, the usefulness 
of the head condition and its generalisation. We also exhibit an interesting rela- 
tionship between the head condition and polymorphie reeursion [15]. Section 6 
concludes by mentioning possible applications of these results. 



2 Preliminaries 

We assume familiarity with the standard concepts of logic programming [17]. 
To simplify the notation, a vector such as oi, . . . , Om is often denoted by b. The 
restriction of a substitution 9 to the variables in a syntactic object o is denoted 
as 6\o, and analogously for type substitutions (see Subsec. 2.2). The relation 
symbol of an atom a is denoted by Rel(a). 

When we refer to a elause in a program, we usually mean a copy of this clause 
whose variables are renamed apart from variables occurring in other objects in 
the context. A query is a sequence of atoms. A query Q' is derived from a query 
Q, denoted Q Q' , if Q = Q' = (ai, . . . ,ak-i, B,Ok+i, ■ ■ ■ ,am)9, 

and /i t— B is a clause (in a program usually clear from the context) such that 
h and Ok are unifiable with MGU 6. A derivation Q '^* Q' is defined in the 
usual way. Given a program P, the immediate consequence operator Tp is 
defined by Tp{M) = {h6 j /i t— oi, . . . , Om G P, a\6 , . . . , Omd G M}. 



^ A variant is obtained by renaming the type parameters in a type. 
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2.1 Derivation Trees 

A key element of this work is the proof-theoretic semantics of logic programs 
based on derivation trees [6]. We recall some important notions and basic results. 

Definition 2.1. An instance name of a clause C is a pair of the form {C,6), 
where 0 is a substitution. 

Definition 2.2. Let P be a program. A derivation tree for P is a labelled 
ordered tree [6] such that: 

1. Each leaf node is labelled by _L or an instance name {C, 6) of a clause^ in P; 
each non-leaf node is labelled by an instance name {C,6) of a clause in P. 

2. If a node is labelled by {h •<— ai, . . . ,am,0), where to > 0, then this node 
has TO children, and for i € {1, . . . ,to}, the ith child is labelled either _L, or 
{h' •<— B,6') where h'6' = aiO. 

Nodes labelled _L are incomplete, all other nodes are complete. A derivation 
tree containing only complete nodes is a proof tree. 

To define the semantics of logic programs, it is useful to associate an atom 
with each node in a derivation tree in the following way. 

Definition 2.3. Let T be a derivation tree. For each node n in T, the node 
atom of n, denoted atom{n), is defined as follows: If n is labelled {h •<— B,9), 
then h9 is the node atom of n; if n is labelled _L, and n is the ith child of its 
parent labelled (/i •<— oi , . . . , a™, 9), then Ui9 is the node atom of n. If n is the 
root of T then atom{n) is the head of T, denoted head{T). 

Derivation trees are obtained by grafting instances of clauses of a program. 
To describe this construction in a general way, we define the following concept. 

Definition 2.4. Let P be a program. A skeleton (tree) for P is a labelled 
ordered tree such that: 

1. Each leaf node is labelled by _L or a clause in P, and each non-leaf node is 
labelled by a clause in P. 

2. If a node is labelled by /i •<— oi , . . . , a™, where to > 0, then this node has to 
children, and for i € {1, . . . ,to), the ith child is labelled either _L, or /i' •<— P 
where Rel(h') = Rel{ai). 

The skeleton of a tree T, denoted Sk{T), is the skeleton obtained from T 
by replacing each label {C, 9) with C. Conversely, we say that T is a derivation 
tree based on Sk{T). 

Recall that C is renamed apart from any other clause in the same tree. 



2 
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h(X)^q(X),p(X). 

q(D)- 

p(X) ^ r(X). 



(h(X) ^ q(X), p(X), {x/[]}) h(X) ^ q(X), p(X) 

/ \ / \ 

(q([]),0) (p(X') ^ r(X'), {x'/D}) q([]) p(X') ^ r(X') 

_L _L 



Fig. 1. A program, a derivation tree and its skeleton 



Definition 2.5. Let 5 be a skeleton. We define 

Eq{S) = {tti = h' I there exist complete nodes n, n' in S such that 

• n' is the ith child of n, 

• n is labelled /i -t— oi , . . . , am, 

• n' is labelled /i' -t— B} 

Abusing notation, we frequently identify the set of equations with the conjunc- 
tion or sequence of all equations contained in it. If Eq{S) has a unifier then we 
call S a proper skeleton. 

Proposition 2.1. [6, Prop. 2.1] Let 5 be a skeleton. A derivation tree based on 
S exists if and only if S is proper. 

Theorem 2.2. [6, Thm. 2.1] Let 5 be a skeleton and 9 an MGU of Eq(S). Let 
D{S) be the tree obtained from S by replacing each node label C with the pair 
(C,9\c)- Then D{S) is a most general derivation tree based on 5 (i.e., any other 
derivation tree based on S is an instance of D{S)). 

Example 2.1. Figure 1 shows a program, one of its derivation trees, and the 
skeleton of the derivation tree. 

To model derivations for a program P and a query Q, we assume that P 
contains an additional clause go Q, where go is a new predicate symbol. 

We recall the following straightforward correspondences between derivations, 
the Tp-semantics and derivation trees. 

Proposition 2.3. Let P be a program. Then 

1. a e lfp{Tp) if and only if a = head{T) for some proof tree T for P, 

2. Q Q' if and only if Q' is the sequence of node atoms of incomplete nodes 
of a most general derivation tree for PU {go •<— Q) with head go, visited left 
to right. 



2.2 Typed Logic Programming 

We assume a type system for logic programs with parametric polymorphism but 
without subtyping, as realised in the languages Godel [12] or Mercury [27]. 
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Table 1. Rules defining a typed language 



(Var) {x : T, . . X : T 



(Func) 
(Atom) 
( Query) 



( Clause) 



UHi'.TiO ■■■ U\-tm-Tm& 

UHi:ti6 ■■■ UHm:-Tm.0 
Atom 

U\-Ai Atom ••• U\-Am Atom 
U\-Ai,...,Am Query 

U\-A Atom U\-Q Query 
U\-A-^Q Clause 



0 is a type substitution 
0 is a type substitution 



( Program ) 



J~Ci Clause ••• _l~C'm Clause 
J-{Ci,...,Cm} Program 



( Querys et) 



J-Qi Query ■■■ JrQm Query 
Jr{Qi,...,Qm} Queryset 



The set of types T is given by the term structure based on a finite set of 
constructors fC, where with each K £ fC an arity to > 0 is associated (by 
writing K /m), and a denumerable set lA of parameters. A type substitution 
is an idempotent mapping from parameters to types which is the identity almost 
everywhere. The set of parameters in a syntactic object o is denoted by pars{o). 

We assume a denumerable set V of variables. The set of variables in a 
syntactic object o is denoted by vars(o). A variable typing is a mapping from 
a finite subset of V to T, written as {xi : ri, . . . , Xm ■ Tm}- 

We assume a finite set T (resp. V) of function (resp. predicate) sym- 
bols, each with an arity and a declared type associated with it, such that: 
for each f £ T, the declared type has the form (n , . . . , r^, t), where to is the 
arity of /, (ri,...,Tm) £ T™, and r satisfies the transpareney eondition [13]: 
parslyTi, . . . ,Tm) C pars(r)\ for each p £ V, the declared type has the form 
(ti , . . . , T m), where to is the arity of p and (ti,. . . ,Tm) G T™. We often indicate 
the declared types by writing and Pn...r ™5 however we assume that 

the parameters in n , . . . , , t are fresh for each occurrence of / or p. We assume 

that there is a special predicate symbol =u,u where u £U. 

Throughout this paper, we assume fC, T , and V arbitrary but fixed. The 
typed language, i.e. a language of terms, atoms etc. based on fC, T , and V , is 
defined by the rules in Table 1. All objects are defined relative to a variable typing 
[/, and _ h . . . stands for “there exists U such that U h . . .”. The expressions 
below the line are called type judgements. 

Formally, a proof of a type judgement is a tree where the nodes are labelled 
with judgements and the edges are labelled with rules (e.g. see Fig. 2) [29]. 
From the form of the rules, it is clear that in order to prove any type judgement, 
we must, for each occurrence of a term t in the judgement, prove a judgement 
. . . h t : r for some r. We now define the most general such r. It exists and can 
be computed by type infereneing algorithms [2]. 
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t/ h ti : Ti 



U \~ tin • 



U \- i : f U h Atom U \~ Atom 

U h p{t) Atom u ^ pijti), . . . ,Pm{tm) Query 

U p{i) ■(— pi{ii), ■ ■ ■ ,Pm{im) Clause 



Fig. 2. Proving a type judgement 



Definition 2.6. Consider a judgement U h p(F) -t— pi(ti), . . . ,Pm{tm) Clause 
and a proof of this judgement containing judgements U t : f, U ti : fi, 
. . . , U \- tm ■ Tm (see Fig. 2) such that . . . ,fm) is most general (wrt. 

all such proofs). We call . . . ,fm) the most general type of p{t) -t— 

Pi{ii), ■ ■ ■ ,Pm{im) wrt. U. 

Moreover, consider the variable typing U' and the proof of U' h p{t) -t— 
Pi(ii), ■ ■ ■ ,Pm.(im) Clause containing judgments U' \~ i : f, U' \~ i\ : ri, ..., 
U' \- tm ■ fm such that (r,Ti, . . . ,Tm) is most general (wrt. all such proofs 
and all possible U'). We call (r,ri, . . . ,Tm) the most general type of p{t) •<— 
Pl(tl); • • • ‘ 

The following example explains the difference between the most general type 
wrt. a fixed variable typing, and the most general type as such. 

Example 2.2. Consider function nil_j.iist(u) and clause C = p •<— X = nil, nil = 
nil. Fixing U = {X : list(int)}, the judgement U C Clause can be proven 
using the judgements U \~ X : list(int) and then U h nil : list(int) for 
eaeh occurrence of nil. It can also be proven using the judgements U X : 
list(int) and then U h nil : list(int) (for the first occurrence of nil) and 
then U h nil : list(V) (for the other two occurrences of nil). In the latter 
case, we obtain (list(int), list(int), list(V), list(V)), the most general type 
of C wrt. U. Moreover, (list(V'), list(V'), list(V), list(V)) is the most general 
type of C (choose U' = {X : list(V')}). 

Definition 2.7. If U \~ xi = ti, . . . , Xm = tm Query where xi,. . . , Xm are dis- 
tinct variables and for each i € {!,... ,m}, ti is a term distinct from Xi, then 
{{xi/ti, . . . ,Xm/tm},U) is a typed (term) snbstitntion. 

3 Subject Reduction for Derivation Trees 

We first define subject reduction as a property of derivation trees and show 
that it is equivalent to the usual operational notion. We then show that a suf- 
ficient condition for subject reduction is that the types of all unified terms are 
themselves unifiable. 
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3.1 Proof-Theoretic and Operational Snbject Rednction 

Subject reduction is a well-understood concept, yet it has to be defined formally 
for each system. We now provide two fundamental definitions. 

Definition 3.1. Let _ h P Program and _ h Q Queryset. We say P has (proof- 
theoretic) snbject rednction wrt. Q if for every Q £ Q, for every most 
general derivation tree T for PU {go •<— Q} with head go, there exists a variable 
typing U' such that for each node atom a of T, P' h a Atom. 

P has operational snbject rednction wrt. Q if for every Q £ Q, for every 
derivation Q Q' of P, we have Q' Query. 

The reference to Q is omitted ii Q = {Q \ - \~ Q Query}. The following 
theorem states a certain equivalence between the two notions. 

Theorem 3.1 (Proof see [8]). Let _ h P Program and _ b Q Queryset. If P 
has subject reduction wrt. Q, then P has operational subject reduction wrt. Q. 
If P has operational subject reduction, then P has subject reduction. 

The following example shows that in the second statement of the above the- 
orem, it is crucial that P has operational subject reduction wrt. all queries. 

Example 3.1. Let K. = {list/1, int/0), T = {nil_j.ii^t(u), consD^iist(u)-i-iist(u), 
1— f int t d— f int 7 • • ■ { 7 P {Plist (int) t ^list (U) 1 7 aud P be 

p(X) <- r(X). r([X]) <- r(X). 

For each derivation p(X) Qg, we have Qg = p(Y) or Qg = r(Y) for some 
Y e V, and so {Y : list(int)} h p(Y) Query or {Y : list(U)} h r(Y) Query. 
Therefore P has operational subject reduction wrt. {p(X)}. Yet the derivation 
trees for P have heads p(Y), p([Y]), p([[Y]]) etc., and _ \/ p([[Y]]) Query. 

3.2 Unifiability of Types and Subject Reduction 

We now lift the notion of skeleton to the type level. 

Definition 3.2. Let _ h P Program and 5 be a skeleton for P. The type 
skeleton corresponding to S' is a tree obtained from S by replacing each 
node label P„ = p{t) ■(- Pi{ti), ■ ■ ■ with p{f) ■(- Pi{fi), . . . ,Pm{fm), 

where (r,ri, . . . ,fm) is the most general type of C„.^ For a type skeleton TS, 
the type equation set Eq( TS) and a proper type skeleton are defined as in 
Def. 2.5. 

The following theorem states that subject reduction is ensured if terms are 
unified only if their types are also unifiable. 

Theorem 3.2. Let _ h P Program and _ b Q Queryset. P has subject reduction 
wrt. Q if for each proper skeleton S of PU{go •<— Q) with head go, where Q G Q, 
the type skeleton corresponding to S is proper. 

The proof uses a statement that unification of terms of the same type yields 
a typed substitution [8]. 

® Recall that the variables in Cn and the parameters in r, ri , . . . , -fm are renamed apart 
from other node labels in the same (type) skeleton. 
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go e- 


■p(x) 


go -(r- p(list(int)) 
1 


p(X') c 


- r(X') 


1 

p(list(int)) .f— 


r(list(int)) 


r([X"]) ■ 


^ r(X") 


r(list(U”)) 


^ r(U") 


r([X"']) ■ 


<- r(X"') 


r(list(U”')) 


^ r(U"') 



Fig. 3. A skeleton and the corresponding non-proper type skeleton for Ex. 3.1 



app([] ,Ys,Ys) . 
app([X|Xs] ,Ys, [X|Zs]) <- 
app (Xs , Ys ,Zs) . 



*/,app (list (U) ,list(U) ,list(U)) 
’/, app (list (U) ,list(U) ,list(U)) 
’/, app (list (U) ,list(U) ,list(U)) 



r([l]). 



*/,r (list (int) ) 



go <- 

app(Xs, [] ,Zs) , 
r (Xs) . 



'/, app (list (int) ,list(int) ,list(int)) 
'/,r (list (int) ) 



Fig. 4. A program used to illustrate type skeletons 



Example 3.2. Figure 3 shows a proper skeleton and the corresponding non- 
proper type skeleton for the program in Ex. 3.1. 

In contrast, let K. and T be as in Ex. 3.1, and V = {appiist(u).iist(u).iist(u)j 
riist(int)}- Let P be the program shown in Eig. 4. The most general type of each 
clause is indicated as comment. Eigure 5 shows a skeleton S and the correspond- 
ing type skeleton TS for P. A solution of Eq{ TS) is obtained by instantiating 
all parameters with int. 



4 Conditions for Subject Reduction 

By Thm. 3.2, a program has subject reduction if for each proper skeleton, the 
corresponding type skeleton is also proper. A more general sufficient condition 
consists in ensuring that any type skeleton is proper. We call this property type 
unifiability. Arguably, type unifiability is in the spirit of prescriptive typing, 
since subject reduction should be independent of the unifiability of terms, i.e., 
success or failure of the computation. However this view has been challenged in 
the context of higher-order logic programming [21]. 

We conjecture that both subject reduction and type unifiability are undecid- 
able. Proving this is a topic for future work. 

4.1 The Head Condition 

The head condition is the standard way [13] of ensuring type unifiability. 
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go -i- app(Xs, 0,Zs) , r(Xs) 



app([X'|Xs'],Ys',[X'|Zs']) 
app(Xs', Ys', Zs') 



^(W) 



go ■«— app(list(int)^) , r(list(int)) 

/ \ 

app(list(U')^) 



app(list(U')^) 

app(list(U”)^) 



r(list(int)) 



app([],Ys",Ys") 

Fig. 5. A skeleton and the corresponding type skeleton for Ex. 3.2 



Definition 4.1. A clause C = Pf{t) f— B fulfills the head condition if its 
most general type has the form (f , . . .). 

Note that by the typing rules in Table 1, clearly the most general type of C 
must be (f , . . .)& for some type substitution 0. Now the head condition states 
that the type of the head arguments must be the declared type of the predicate, 
or in other words, 0\f= 0- It has been shown previously that typed programs 
fulfilling the head condition have operational subject reduction [13, Thm. 1.4.7]. 
By Thm. 3.1, this means that they have subject reduction. 

4.2 Generalising the Head Condition 

To reason about the existence of a solution for the equation set of a type skeleton, 
we give a sufficient condition for unifiability of a finite set of term equations. 

Proposition 4.1. Let E = {li = ri, ... ,lm = I’m} be a set of oriented equa- 
tions, and assume an order relation on the equations such that l\ = r\ ^ I 2 = r 2 
if ri and I 2 share a variable. E is unifiable if 

1. for all 1 < i < j < TO, Vi and Vj have no variable in common, and 

2. the graph of is a partial order, and 

3. for alH e {1, . . . , to}, k is an instance of r,. 

In fact, the head condition ensures that Eq{TS) meets the above conditions 
for any type skeleton TS. The equations in Eq{ TS) have the form p{fa) = p{fh), 
where fa is the type of an atom and fh is the type of a head. Taking into account 
that the “type clauses” used for constructing the equations are renamed apart, 
all the head types (r.h.s.) have no parameter in common, the graph of is a 
tree isomorphic to TS, and, by the head condition, fa is an instance of f/j. In 
the next subsection, we show that by decomposing each equation p{fa) = p{fh), 
one can refine this condition. 

4.3 Semi-generic Programs 

In the head condition, all arguments of a predicate in clause head position are 
“generic” (i.e. their type is the declared type). One might say that all argu- 
ments are “head-generic” . It is thus possible to generalise the head condition by 
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partitioning the arguments of each predicate into those which stay head-generic 
and those which one requires to be generic for body atoms. The latter ones will 
be called body-generic. If we place the head-generic arguments of a clause head 
and the body-generic arguments of a clause body on the right hand sides of the 
equations associated with a type skeleton, then Condition 3 in Prop. 4.1 is met. 

The other two conditions can be obtained in various ways, more or less com- 
plex to verify (an analysis of the analogous problem of not being subject to occur 
check (NSTO) can be found in [6]). Taking into account the renaming of “type 
clauses” , a relation between two equations amounts to a shared parameter be- 
tween a generic argument (r.h.s.) and a non-generic argument (l.h.s.) of a clause. 
We propose here a condition on the clauses which implies that the equations of 
any skeleton can be ordered. 

In the following, an atom written as p{s, t) means: s and t are the vectors of 
terms filling the head-generic and body-generic positions of p, respectively. The 
notation p(a,f), where a and r are types, is defined analogously. 

Definition 4.2. Let _ h P Program and _ h C* Clause where 

^ Pfo,5m.+ l (^Oj Sm-|-l) Pai,fl (®1 5 fl)j • • • ■’P3m,Tm ^ m ) J 

and 0 the type substitution such that (tq, (fm-i-i , (fi , ri , . . . , dm, fm)0 is the most 
general type of C . We call C semi-generic if 

1. for all ijj e {0, . . . ,m}, i j, pars(riO) Ci pars(Tj0) = 0, 

2. for all i G {1, . . . ,to}, pars(ai) n U*<j<m 

3. for all i G {0, . . . ,m}, Ti& = r,. 

A query Q is semi-generic if the clause go t— Q is semi-generic. A program 
is semi-generic if each of its clauses is semi-generic. 

Note that semi-genericity has a strong resemblance with nicely-modedness, 
where head-generic corresponds to input, and body-generic corresponds to out- 
put. Nicely-modedness has been used, among other things, to show that pro- 
grams are free from unification [1] . Semi-genericity serves a very similar purpose 
here. Note also that a typed program which fulfills the head condition is semi- 
generic, where all argument positions are head-generic. 

The following theorem states subject reduction for semi-generic programs. 

Theorem 4.2 (Proof see [8]). Every semi-generic program P has subject 
reduction wrt. the set of semi-generic queries. 

The following example shows that our condition extends the class of programs 
that have subject reduction. 

Example 4-1. Suppose fC and T define lists as usual (see Ex. 3.1). Let V = 
{Pu,v,qu,v} and assume that for p,q, the first argument is head-generic and the 
second argument is body-generic. Consider the following program. 
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p(U,list(V)) ^ q(list(U),W),q(list(W),V) 



/ 

q(U',list(U')) 




q(U",list(U")) 



Fig. 6. A type skeleton for a semi-generic program 



p(X,[Y]) <- y.p(U,list(V)) <- 

q([X] ,Z) , q([Z] ,Y) . I q(list (U) ,W) , q(list (W) , V) . 
q(X,[X]). y.q(U,list(U)) . 

This program is semi-generic. E.g. in the first type clause the terms in generic 
positions are U, W,V; all generic arguments have the declared type (condition 3); 
they do not share a parameter (condition 1); no generic argument in the body 
shares a parameter with a non-generic position to the left of it (condition 2) . A 
type skeleton is shown in Fig. 6. 

As another example, suppose now that K. and T define list and integers, and 
consider the predicate r/2 specified as r(l, []),r(2, [[]]), r(3, [[[]]]) . . .. Its obvious 
definition would be 

r(l,[]). 

r(J,[X]) <- r(J-l,X). 

One can see that this program must violate the head condition no matter 
what the declared type of r is. However, assuming declared type (int, list(U)) 
and letting the second argument be body-generic, the program is semi-generic. 

One can argue that in the second example, there is an intermingling of the 
typing and the computation, which contradicts the spirit of prescriptive typing. 
However, as we discuss in the next section, the situation is not always so clearcut. 

5 What is the Use of the Head Condition? 

The above results shed new light on the head condition. They allow us to view it 
as just one particularly simple condition guaranteeing type unifiability and con- 
sequently subject reduction and “well- typing” of the result, and hence a certain 
correctness of the program. This raises the question whether by generalising the 
condition, we have significantly enlarged the class of “well-typed” programs. 

However, the head condition is also sometimes viewed as a condition in- 
herent in the type system, or more specifically, an essential characteristic of 
generic polymorphism, as opposed to ad-hoc polymorphism. Generic polymor- 
phism means that predicates are defined on an infinite number of types and that 
the definition is independent of a particular instance of the parameters. Ad- 
hoc polymorphism, often called overloading [19], means, e.g., to use the same 
symbol + for integer addition, matrix addition and list concatenation. Ad-hoc 
polymorphism is in fact forbidden by the head condition. 
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One way of reconciling ad-hoc polymorphism with the head condition is to 
enrich the type system so that types can be passed as parameters, and the 
definition of a predicate depends on these parameters [18] . Under such conditions, 
the head condition is regarded as natural. 

So as a second, more general question, we discuss the legitimacy of the head 
condition briefly, since the answer justifies the interest in our first question. 

In favour of the head condition, one could argue (1) that a program typed in 
this way does not compute types, but only propagates them; (2) that it allows for 
separate compilation since an imported predicate can be compiled without con- 
sulting its definition; and (3) that it disallows certain “unclean” programs [22]. 

In reality, these points are not, strictly speaking, fundamental arguments in 
favour of the head condition. Our generalisation does not necessarily imply a 
confusion between computation and typing (even if the result type does not de- 
pend on the result of a computation, it may be an instance of the declared type). 
Moreover, if the type declarations of the predicates are accompanied by decla- 
rations of the head- and body-generic arguments, separate compilation remains 
possible. Finally, Hanus [11] does not consider the head condition to be particu- 
larly natural, arguing that it is an important feature of logic programming that 
it allows for lemma generation. 

We thus believe that the first question is, after all, relevant. So far, we have 
not been able to identify a “useful” , non-contrived, example which clearly shows 
the interest in the class of semi-generically typed programs. The following ex- 
ample demonstrates the need for a generalisation, but also the insufficiency of 
the class defined in Def. 4.2. 

Example 5.1. Let fC = {t/1, int/0} and 

^ = { — l-i-int, 0_j.int , • • ■ , C_j.t(u) , gu-j.t(U)j f t(t(U))->t(U) }• 

For all i > 0, we have _ h g*(c) : t*+^(U) and _ h f*(g*(c)) : t(U). This means 
that the set {a \ 3s, t. s is subterm oft, _ h s : cr, _ h t : t(U)} is infinite, or in 
words, there are infinitely many types that a subterm of a term of type t(U) 
can have. This property of the type t(U) is very unusual. In [26], a condition is 
considered (the Reflexive Condition) which rules out this situation. 

Now consider the predicate fgs/2 specified as fgs(t, f *(g*(c))) {i € IN). Fig- 
ure 7 presents three potential definitions of this predicate. The declared types are 
given by V = {fgslint,t(U), gslint.t(u), fgs2int.t(u), fgs3int,t(u), fsli„t,t(U).int, 
fs2int,t(u).int, gs2int,t(u).t(v), f gs3_auXint ,t (u) ,t (u) } • The first solution is the most 
straightforward one, but its last clause does not fulfill the head condition. For the 
second solution, the fact clause gs2(0,x,x) . does not fulfill the head condition. 
The third program fulfills the head condition but is the least obvious solution. 

For the above example, the head condition is a real restriction. It prevents 
a solution using the most obvious algorithm, which is certainly a drawback of 
any type system. We suspected initially that it would be impossible to write a 
program fulfilling the specification of fgs without violating the head condition. 
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fgsKi.Y) <- 
fsl(I,Y,I) . 

fsl(I,f(X) ,J) <- 
fsl(I-l,X, J) . 
fsl(0,X,J) <- 
gsKJ.X) . 

gsl(J,g(X)) <- 
gsl(J-l,X) . 
gsl(0,c) . 



fgs2(I,Y) <- 
fs2(I,Y,I). 

fs2(I,f (X) , J) <- 
fs2(I-l,X,J) . 
fs2(0,X,J) <- 
gs2(J,X,c). 

gs2(J,X,Y) <- 
gs2(J-l,X,g(Y)). 
gs2(0,X,X). 



fgs3(I,X) <- 

fgs3_aux (I , c ,X) . 

fgs3_aux (I ,X ,f (Y) ) <- 
fgs3_aux(I-l,g(X) ,Y) . 
fgs3_aux (0 ,X ,X) . 



Fig. 7. Three potential solutions for Ex. 5.1 



Now it would of course be interesting to see if the first two programs, which 
violate the head condition, are semi-generic. Unfortunately, they are not. We 
explain this for the first program. The second position of gsl must be body- 
generic because of the second clause for gsl. This implies that the second position 
of f si must also be body-generic because of the second clause for f si (otherwise 
there would be two generic positions with a common parameter) . That however 
is unacceptable for the first clause of fsl (X has type t(t(U)), instance of t(U)). 

It can however be observed that both programs have subject reduction wrt. 
the queries fgsj(i,Y) for i € IN and j = 1,2. In fact for these queries all type 
skeletons are proper, but it can be seen that the equations associated with 
the type skeletons cannot be ordered. This shows that the condition of semi- 
genericity is still too restrictive. 

There is a perfect analogy between gsl and r in Ex. 4.1. 

To conclude this section, note that our solution to the problem in Ex. 5.1 uses 
polymorphic recursion, a concept previously discussed for functional program- 
ming [15]: In the recursive clause for fgs3_aux, the arguments of the recursive 
call have type (int,t(t(U)),t(t(U))), while the arguments of the clause head 
have type (int,t(U),t(U)). If we wrote a function corresponding to fgs3_aux in 
Miranda [30] or ML, the type checker could not infer its type, since it assumes 
that recursion is monomorphic, i.e., the type of a recursive call is identical to 
the type of the “head” . In Miranda, this problem can be overcome by providing 
a type declaration, while in ML, the function will definitely be rejected. This 
limitation of the ML type system, or alternatively, the ML type checker, has 
been studied by Kahrs [14]. 

There is a certain duality between the head condition and monomorphic 
recursion. When trying to find a solution to our problem, we found that we either 
had to violate the head condition or use polymorphic recursion. Eor example, 
in the recursive clause for gsl, the arguments of the recursive call have type 
(int,t(U)), while the arguments of the clause head have type (int, t(t(U))), 
which is in a way the reverse of the situation for fgs3_aux. Note that this 
implies a violation of the head condition for any declared type of gsl. It would 
be interesting to investigate this duality further. 




Well-Typed Logic Programs Are not Wrong 293 



6 Conclusion 

In this paper we redefined the notion of subject reduction by using derivation 
trees, leading to a proof-theoretic view of typing in logic programming. We 
showed that this new notion is equivalent to the operational one (Thm. 3.1). 

We introduced type skeletons, obtained from skeletons by replacing terms 
with their types. We showed that a program has subject reduction if for each 
proper skeleton, the type skeleton is also proper. Apart from clarifying the mo- 
tivations of the head condition, it has several potential applications: 

— It facilitates studying the semantics of typed programs by simplifying its 
formulation in comparison to other works (e.g. [16]). Lifting the notions of 
derivation tree and skeleton on the level of types can help formulate proof- 
theoretic and operational semantics, just as this has been done for untyped 
logic programming with the classical trees [3,6,9]. 

— The approach may enhance program analysis based on abstract interpreta- 
tion. Proper type skeletons could also be modelled by fixpoint operators [4, 
5,10]. Abstract interpretation for prescriptively typed programs has been 
studied by [24,26], and it has been pointed out that the head condition 
is essential for ensuring that the abstract semantics of a program is finite, 
which is crucial for the termination of an analysis. It would be interesting 
to investigate the impact of more general conditions. 

— This “proof-theoretic” approach to typing could also be applied for synthesis 
of typed programs. In [28], the authors propose the automatic generation 
of lemmas, using synthesis techniques based on resolution. It is interesting 
to observe that the generated lemmas meet the head condition, which our 
approach seems to be able to justify and even generalise. 

— The approach may help in combining prescriptive and descriptive approaches 
to typing. The latter are usually based on partial correctness properties. 
Descriptive type systems satisfy certain criteria of type-correctness [7], but 
subject reduction is difficult to consider in such systems. Our approach is a 
step towards potential combinations of different approaches. 

We have presented a condition for type unifiability which is a refinement of 
the head condition (Thm. 4.2). Several observations arise from this: 

— Definition 4.2 is decidable. If the partitioning of the arguments is given, 
it can be verified in polynomial time. Otherwise, finding a partitioning is 
exponential in the number of argument positions. 

— The refinement has a cost: subject reduction does not hold for arbitrary 
(typed) queries. The head condition, by its name, only restricts the clause 
heads, whereas our generalisation also restricts the queries, and hence the 
ways in which a program can be used. 

— As we have seen, the proposed refinement may not be sufficient. Several 
approaches can be used to introduce further refinements based on abstract 
interpretation or on properties of sets of equations. Since any sufficient con- 
dition for type unifiability contains at least an NSTO condition, one could 
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also benefit from the refinements proposed for the NSTO check [6]. Such 
further refined conditions should, in particular, be fulfilled by all solutions 
of Ex. 5.1. 

We have also studied operational subject reduction for type systems with 
subtyping [25]. As future work, we want to integrate that work with the proof- 
theoretic view of subject reduction of this paper. Also, we want to prove the 
undecidability of subject reduction and type unifiability, and design more refined 
tests for type unifiability. 
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Abstract. The paper presents a novel approach to the analysis of typed 
logic programs. We assume regular type descriptions of logic program 
variables provided by regular tree grammars. Types are used to identify 
components of terms which can be equated during the programs execu- 
tion. This information is reflected in form of set constraints in the generic 
abstract domain called Type(X). The domain allows for abstract compi- 
lation of typed logic programs into set logic programs. We demonstrate 
how the analyzers of groundness and .sharing of typed logic programs are 
obtained by applying the existing (untyped) techniques based on Pos and 
Sharing to set logic programs. The corresponding analyses in Type(Pos) 
and Type(Sharing) are more precise than those in Pos and Sharing. 



1 Introduction 

Recent logic programming languages Godel [10], Mercury [19] and HAL [5] are 
strongly typed, using variations of Hindley-Milner [15] type systems. Prescrip- 
tive type information is useful for detecting many simple programming errors, 
and gives a new source of information to use in optimizing compilation. The 
advantages of type information in efficient execution are well illustrated by the 
performance of Mercury programs. Additionally systems [6] exist for automati- 
cally inferring regular tree types from programs. Once such a type is inferred we 
can use the information in later analyses to improve the accuracy of the results. 

In this paper we examine how we can analyze (regular-tree) typed logic pro- 
grams. Analysis of typed logic programs is important for optimizing compilation 
of Mercury and HAL. 

Types allow analyses to be more accurate than analyses of the corresponding 
untyped programs. For example consider the analysis of the typed “append” 
program shown in Figure 1. The types of A, B, C, D and E are lists. A typed 
analysis separates a list variable v into two parts, the skeleton of the list Ly, and 
the elements of the list Ey. The analysis creates a CLP(B) program relating the 
boundness of these different parts of the list. The bottom-up abstract evaluation 
of abstract “append” results in: 

a.-ppend{{LA, Ea), {Lb, Eb), {Lc, Ec)) La, Lb ^ Lc, Ec^EaLEb. 

H. Kuchen and K. Ueda (Eds.): FLOPS 2001, LNCS 2024, pp. 296-310, 2001. 
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append (A, B,C) 
A = [] , 

B = C. 



append({LA, Ea), {Lb, Eb), {Lc, Ec)) '■ ~ 
La ^ ^ T , Ea ^ ^ T , 

Lb Lc , Eb Ec ■ 



append (A, B,C) 

A = [XID] , 

C = [XIE] , 
append (D,B,E) . 



append({LA, Ea), {Lb, Eb), {Lc, Ec)) ■ ~ 
La Ld , Ea > Ex A Eb> , 

Lc Le , Ec Ex A Ee , 

append({Lo, Ed), {Lb, Eb), {Le, Ee)) ■ 



Fig. 1. Abstraction of append 



showing that on success the list skeleton of A is fixed and the skeleton of B is 
fixed if and only if that of C is, and the elements are related in the usual way. This 
more specific information can be used to improve program optimizations. The 
usual groundness analysis of “append” only gives the answer C ^ A A B, i.e. C 
is ground if and only if A and B are ground. With this information it is not 
possible to determine that the goal append ( [A, B] , [C,D] ,E) , append (E,F,G) 
will result in the list skeleton of E being fixed. This might prevent a partial 
evaluator evaluating the second call to “append” . 

It is important to stress that the type-based analyses proposed in this paper 
are not only more expressive as can be seen from the above example but also more 
precise in a strict sense. As a simplest example consider the unification f{A, B) = 
f{C,D). While the standard Pos approximation of groundness produces {A A 
B) ^ {C A D), in our type-based analysis we may get {A ^ C) A {B ^ D), 
which is clearly a more precise Pos approximation. 

The rest of the paper is organized as follows. In the next section we give 
some preliminary definitions, in particular those for deterministic tree automata 
and deterministic regular tree grammars. In Section 3 we define how we can 
relate the types of variables occurring in constraints. In Section 4, we present the 
parametric abstract domain Type(X) which adds type information to an abstract 
domain X, as well as the corresponding abstraction of typed logic programs into 
programs over set constraints. In Sections 5 and 6 we present the techniques 
of groundness and sharing analysis of typed logic programs based on Type(X). 
Finally, in Section 7 we provide a brief comparison with some related works and 
conclude. 

2 Preliminaries 

In the following we assume a familiarity with the standard definitions and nota- 
tion for logic programs as described in [13] and with the framework of abstract 
interpretation [4] . For a set of function symbols E and variables V, we let T{E, V) 
denote the set of terms constructed using symbols from E and variables from V. 
The set of atoms constructed using predicate symbols from 77 and terms from 
T{E, V) is denoted by B. The set of variables occurring in a syntactic object s 
is denoted vars(s). We say that a term t is ground if vars(t) = 0. 
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We assume the rules of the program are in canonical form. That is, pro- 
cedure calls and rule heads are normalized such that parameters are distinct 
variables, unifications are broken into sequences of simple unification constraints 
and nested terms are flattened by introducing intermediate variables. Unification 
constraints are elements of the set C and can be either in the form X = Y, where 
both X and Y are variables, or in the form X = /(hi, . . . , W), where //n G X, 
n > 0 and X,Yi,...,Yn are variables. A body of a rule in canonical form con- 
tains only unification constraints and procedure calls in the form p(Xi , . . . , 
where p/n G U is a predicate symbol and Xi,...,Xn are distinct variables 
(parameters). In addition, the heads of each rule for predicate p are required 
to be identical atoms p(Xpi, . . . , Xp„), and every variable not appearing in the 
head of a rule is required to appear in exactly one rule. It is straightforward 
to convert any logic program to this canonical form. The concrete (left-hand) 
side of “append” shown in Figure 1 is in canonical form. The domain of facts is 
denoted by Be and consists of rules of the form p{Xi, . . . , X„) <— Ci, . . . ,Ck, 
where Ci . . .Ck are unification constraints. 

Regular Types Deterministic regular types are defined as a class of languages 
accepted by top-down deterministic regular tree automata [7] . The analysis pre- 
sented below can be performed if such regular types are either given explicitly 
as in Mercury,^ or inferred through any mechanism (for example [6]). 

Definition 1 (Top-Down Deterministic Tree Automata). A top-down de- 
terministic finite tree automaton (top-down DFTA) is a tuple A = (qb, Q, X, A), 
where Q is a set of states, qo G Q is an initial state and A is a set of transition 
rules in the form: q{f{xi,...,Xn)) — *■ f{qi{xi),...,qn{xn)), such that no two 
rules have the same left-hand side. 

Top-down deterministic tree automata accept the class of languages called regu- 
lar types, which is a proper subset of regular tree languages and is closed under 
intersection. 

Example 1. The deterministic tree automata A= (qn, {ql, Qb} , {cons/2, a/0, 6/0} , A), 
where Z\ = {(jL (nil)— > nil, (jn(cons(a;, y)) ^ cons(ijB(a;), i}i,(y)), gsia)^ a, <jb( 6)— >6} 
accepts ground lists of a’s and 6’s. 

Definition 2 (Regular Tree Grammar). A regular tree grammar is a tuple 
Q — {S, W, X, A), where: S is a starting non-terminal, W is a finite set of non- 
terminal symbols, s.t. S G W, X is a set of function symbols, A is a set of 
productions in the form X — > f{Yi , . . . , W) s. t. X,Yi . . .Yn G Wand f/n G X. 

Definition 2 is more restrictive than in the standard definitions (e.g. [7]). We 
assume a normal form of productions which allows only one function symbol in 
each rule. However, this restriction is merely syntactic since productions with 
two or more function symbols can always be converted into a normal form by 
introducing new non-terminals. For instance, A — > f{g{X)) can be rewritten 
using a new non-terminal G as A ^ f{G), G g{X). 

^ It is straightforward to convert the Hindley-Milner types of Mercury to (weaker) 
deterministic regular types. 




A Framework for Analysis of Typed Logic Programs 299 



Definition 3 (Deterministic Regnlar Tree Grammars). A regular tree 
grammar Q = (V, W, E, A) as given by Definition 2 is deterministie if for a non- 
terminal X G W and any two corresponding productions {X — > /(K, • • ■ , Xn)) € 
A and {X g{Z \, . . . , Z^)) G A we always have f/n g/m. 

Deterministic regular tree grammars define the same class of languages as top- 
down deterministic tree automata. Moreover, by assuming the normal form of 
grammar we achieve the syntactic uniformity of the two formalisms. Transi- 
tions of an automaton can be converted into grammar productions and vice 
versa by associating each non-terminal symbol with a corresponding state of the 
automaton. 

Example 2. The following regular tree grammar clearly defines the same language as 
accepted by the tree automaton in Example 1: L ^ nil \ cons{E, L), E ^ a \ b. 

The equivalence of regular tree grammars and tree automata allows us for the 
clear and expressive representation of derivations as transitions of a determi- 
nistic rewriting system in the form N{c) — > c for a constant c or in the form 
N{f{ti, . . ,,tn)) — > f{Ni{ti), . . .,Nn{tn)) for f/n G E and n > 0. Using this 
notation we say that the grammar Q = {S, W, E, A) accepts (derives) a term t 
if S{t) -^g t. Sometimes we restrict our attention to a single path or a seg- 
ment of a path of a derivation tree starting from the root (S) and reaching a 
non-terminal N with a subterm t' of t: S{t) —^g N{t'). 

Definition 4 (Acceptance of Non-Ground Terms). A regular tree gram- 
mar Q accepts a non-ground term t, denoted t G E(Q), if and only if it accepts 
some ground instance oft. 

Example S. The grammar shown in Example 2 accepts the terms cons(a, cons(C, nil)) 
and cons(C, D) but not cons(cons(C, nil), nil). 

We assume through the rest of this paper that the term “grammar” refers 
to a deterministic regular tree grammar provided by Definition 3. We also treat 
the terms “state” and “non-terminal” as equivalent and interchangeable due to 
the uniformity of the corresponding formalisms. As a consequence, we make no 
distinction between a “run” of a top-down deterministic tree automaton and a 
“derivation” using a deterministic regular tree grammar. 

3 Properties of Typed Logic Programs 

A typed logic program is a program in canonical form, together with an associ- 
ation of the variables of the program to regular tree grammars. For a variable 
U G V we assume a deterministic regular tree grammar Qy = {Sy, Wy, E, Ay), 
conforming to Definitions 2 and 3. We assume grammars associated with differ- 
ent variables do not involve the same non-terminal symbol (if not we can rename 
appropriately). 

In addition we require that all calls to a predicate name p/n G II have 
the same type (a renaming of the grammar) as the head. This means that all 
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p(X) X = Z, q(Z) . 
q(Y) 



p(X) q(X). 
q(Y) :- ... 

Assuming the types of X, Y and Z are: 

Qx : Lx nil \ cons{Ex, L'x), L'x cons{Ex , Lx), Ex ^ a \ b. 

Qy : Ly nil \ cons(EY,LY), Ey a \ b. 

Qz '■ Lz nil I cons{Ez , Lz), Ez ^ a \ b. 

Fig. 2. Modifying a program so that each predicate call has the same type as the head. 



implicit type casts of procedure parameters are converted into explicit unification 
constraints. For example the program in the left of Figure 2 must be rewritten 
as on the right. 

The analyses presented in this paper assume that the program is well-typed in 
the sense of Mycroft and O’Keefe [17]. That is, the results of analyses approximate 
semantics computed through a sequence of type-correct resolution steps. A type- 
correct resolution step, whether it is top-down or bottom-up, is restricted to 
considering only a type-correct subset of the result. 

Types of Terms Satisfying Program Constraints Let us now lift the 
concept of typing of program variables to the level of unification constraints. 
In particular, we are interested in the internal structure of grammars providing 
the types of terms satisfying the unification constraints. 

The type of terms satisfying a constraint X = F is naturally computed from 
the associated grammars Qx = {Sx,Wx,S,^x) and Qy = {Sy,Wy,S,Ay) 
as a grammar = (5'n) bFn, F, Z\n) for the intersection of (languages of) Qx 
and Qy, where 5'n = {Sx,Sy), Wn is a reachable (through the rules of Z\n) 
subset of Wx X Wy and (Nx, Ny) ^ /((iVi, iV[), . . . (fV„, K)) G Z\n iff Nx ^ 
f{Nu ...,N^)gAx and iVy^/(iV(, . . . , K) G Ziy. 

The type of terms satisfying a constraint X = f{Yi, . . . ,Yn) is computed in 
two steps. First, the types of Yi .. .Yn are combined into a new grammar Qy — 
is f ,Wy , X , Ay) , defining the type of f(Yi, . . . ,YA, s.t. Sf is a new starting 
symbol, Wy = {S'/} U Wy, U • • • U lFy„ and Ziy = {Sf f(Sy,,. .. ,SyJ}U 
Z\y, U • • • U Z\y„ . Then the intersection of (languages of) Qx and Qy is computed 
as shown above. 

It follows that the type of terms satisfying a program constraint corresponds 
to an intersection of (languages of) the grammars of two sides of the constraints. 
Each state of the grammar for this type is in the form {A, B), where A and B are 
non-terminals of the left-hand side and right-hand side grammars respectively. 

Labelling The concept of labelling of non-terminals introduced in this paper 
is a basis for reasoning about the properties of possibly non-ground objects 
with respect to their types. The idea of labelling consists in associating the 
non-terminals of type grammars with sets of variables. In general, the need 
for augmenting the type information with some additional attributes naturally 
arises in the context of any analysis based on regular types. It is motivated by 
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the insufficient expressive power of the underlying type mechanism. For instance, 
dependencies such as “two subterms are identical” or “two variables can share” 
are non-regular and thus, cannot be expressed as regular types. 

Definition 5 (Labelling). A variable V of a non-ground term t labels a non- 
terminal N of a grammar Q if there exists a path in the run of Q on t such that 
S{t) — where S is a starting symbol ofQ. 

In the following we assume a function ({Q,N, t) returning the set of labels of a 
non-terminal N of the grammar Q on its run on a term t. By our assumption 
different grammars have different sets of non-terminal symbols and thus, it is 
always unambiguous to use the more compact notation ({N,t). 

Example 4- Consider the labelling imposed by the term t = \A,B\D] on the non- 
terminals for the regular tree grammar accepting lists: Lx — ^ nil | cons[Ex , Lx)- 
We can see that ({Lx,t) = {E>} since Lx{t) — ^ Lx{D) and f{Ex,t) = since 

Lx{t) ^ Ex (A) and Lx(t) ^ Ex{B). 

The concept of labelling of states (non-terminals) is a basis for the analyses 
shown below in this paper. Labelling allows us to associate different variables of 
a term with different non-terminals of the corresponding regular tree grammar. 
Thus, we can analyze the presence (or absence) of variables, groundness depen- 
dencies, sharing of variables, etc. on the per-role basis, computing more pre- 
cise results than traditional untyped analyses usually operating on the per-term 
basis. For instance, this allows us to analyze groundness of “append” separately 
for list structure and list elements. 

Labelling in Constraint Types Let’s now apply the notion of labelling to 
the results about types of terms satisfying unification constraints. Assume a 
grammar defining the type of terms satisfying a unification constraint C. 
Recall that all non-terminals of Gn can be viewed as pairs (A, B) where A and B 
are non-terminals of the left-hand side grammar Gx and right-hand side grammar 
Gy respectively. Assume that a term t satisfying C labels some non-terminal A 
of Gx by a set of variables S on the run of Gx on t, i.e. ({Gx,A,t) = S. Now 
consider a run of on t. Since defines the intersection of (languages of) Gx 
and Gy, the elements of S can label only the non-terminals {A,B) of Gn, i-C- 
the pairs with A in the hrst position. Thus, in a run of Gy on t, the labels of S 
are divided between all such non-terminals B for which there exists a reachable 
non-terminal {A,B) of ^n- Naturally, the same arguments can be applied in the 
opposite direction, i.e. by hxing a non-terminal B G Wy and reasoning about 
its labels. Thus, for a term t € £(Gn) we have: 

VAgWx- C(A,t) C U(A.B)6Wn (1) 

VBgWy- C(B,t) c U(A,B>6VLn C{A,t). (2) 

Partitions of Non- Terminals As we can see, the sharing of labels by non- 
terminals of grammars Gx and Gy is merely determined by the presence of 
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particular pairs {A, B) in the set of reachable states of the intersection — the 
grammar ^n- The two non-terminals X G Wx and V € Wy can have some 
labels in common if they can be related by some chain of states of Qn, e.g. 
(X, W) ... {Z, W) ... {Z,Y). The more important fact is that a most general 
solution of the unification constraint cannot introduce sharing of labels between 
non-terminals that cannot be related through a chain of states of ^n- In the 
following we formalize these two claims as theorems. 

The notion of related states is formalized as the equivalence relation par- 
titioning the state space W of into the (disjoint) classes of states = 
(Wf), . . . Wp }. The partitioning is induced by the following relation: 

V(A, B) G V(^', B') ^ A ^ A' A B ^ B\ (3) 

We say that two non-terminals X,Y G [Wx U Wy) are dependent if the states of 
Qn including X and the states of Qn including Y appear in the same partition 
of Wn- We say that the non-terminals are independent otherwise. 

Theorem 1. Assume a unification constraint C, the grammars Qx and Qy 
defining respectively the types of the left-hand side and the right-hand side of 
C, the grammar Qn such that C{Gn) = ^{Gx) H L{Qy) and the partitioning 
Wn = {Wf, . . . , Wpfi of states ofQn- Then for any t G C{Gn) and i G {1 . . . fc}; 

y ax,t) = u ay,t) 

{x,Y)ewS {x,Y)ewS 

Proof. In two directions using Equations (1) and (2). 

Theorem 1 provides us with the basic relation for the dependency between 
labelling sets of classes of non-terminals. This relation is based entirely on types 
of variables participating in the corresponding constraints and thus, can be com- 
puted statically. Now let us investigate the other side, i.e. the statically-known 
facts about independence of (labelling of) non-terminals. 

Assume without loss of generality a constraint C ■. X = /(hi, . . . , Yn), the 
grammars Qx and Qy defining respectively the types of the left-hand side and the 
right-hand side of C and the grammar defining the intersection of (languages 
of) Qx and Qy. Assume that the constraint C is solved in the environment ip = 
{X/tx^Y^/tl, . . .Yn/tn}. Thus, solving C consists in finding the most general 
unifier of two terms: tx and ty, where ty = /(ti, . . . , tn). Let 9 — mgu(tx, ty). 
Now assume that A and B are two independent non-terminals of Qx and Qy 
respectively. We claim that solving C cannot introduce any new sharing of labels 
of A and B. In other words, solving C cannot unify a variable from C(A, tx) with 
a variable from ({B,ty). 

Theorem 2. For a unification problem tx = ty with the types of tx and ty 
given by the grammars Qx and Qy, the constraint solution 9 — mgu(tx, W) and 
two independent non-terminals A and B of Qx and Qy respectively: 

f{A,tx)EC,{B,ty) = tb =A C,{A,tx9)C\C,{B,ty9) =tb 
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Corollary 1. Most general solutions of unification constraints never unify vari- 
ables labelling independent non-terminals of type grammars. 

The results of Theorems 1 and 2 lead us to what we see as the main contribution 
of this work. Namely, the fact that by analyzing set constraints similar to the 
one in the claim of Theorem 1 we can obtain correct static approximations of 
properties such as groundness and sharing imposed by the corresponding uni- 
fication constraint. Indeed, Theorem 1 approximates the ways in which labels 
(variables) can be unified when solving the corresponding unification constraint. 
Theorem 2 serves as a safety statement for Theorem 1 claiming that there are no 
other ways in which labels can be unified. Thus, correct descriptions of ground- 
ness and sharing dependencies can be derived using Theorem 1. Moreover, these 
descriptions are in general more precise than the results of traditional untyped 
analyses. This is because in our case the analysis is performed independently on 
the corresponding components of terms (i.e. per-role) and not on whole terms 
as in the traditional approach (e.g. [14]). 

Note that in general the relations as shown in Theorem 1 may not include 
all non-terminals of the corresponding left-hand side and right-hand side gram- 
mars. Assume without loss of generality a non-terminal N of the left-hand side 
grammar Qx- It is possible that the grammar defining the intersection does not 
contain any state in the form {N, N'). It means that no term satisfying the con- 
straint can reach the state N on its run (derivation) in Qx- Thus, f{N, t) =% for 
any t. We want to preserve this information in the abstract domains shown in the 
following sections. Thus, assuming the sets Wx^ Wy and ITn of non-terminals 
of the left-hand side, right-hand side and the intersection grammars respectively 
we define a set of nnreachable non-terminals: 

IT0 = [A&Wx VS G Wy. (A, Bj^Wnj U 

{ BeWy VAe Wx- (A, B) iWn). ^ ^ 

4 Abstraction of Typed Logic Programs 

The analyses described in this paper are constructed using a first order lan- 
guage, similar to that of logic programs, called .set logic programs. In the previous 
works [2,3] set logic programs are shown to be a clean and powerful formalism 
for designing program analyses. 

Syntactically, we assume a set of variables V and an nnderlying alphabet 
S® = {©/2, 0/0} consisting of a single binary function symbol © which “glues” 
elements together and a single constant symbol 0 to represent the empty set. 
Abstract terms, or set expressions, are elements of the term algebra T{U®,V) 
modulo an equality theory consisting of the following axioms: 

{x ® y) ® z = X ® {y ® z) (associativity) x®x = x (idempotence) . . 

X ® y = y ® X (commutativity) x®% = x (unity) ^ ' 

This equality theory is sometimes referred to as ACII and the corresponding 
equivalence relation on terms denoted «. This notion of equivalence suggests 
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that abstract terms can be viewed as flat sets of variables. For example, the 
terms X\®X 2 ® X 3 , x\® X 2 ® xz® 0, and xi®X 2 ®x^® X 2 can each be viewed 
as representing the set {xi,X 2 tX^} of three variables. 

In this work we introduce the abstraction of unification constraints of typed 
logic programs into set constraints (ACIl-uniflcation constraints). Set constraints 
are the elements of the set C® = T (A'®, V) xT(Z'® , V) and are in the form x ^ y, 
where x and y are set expressions. The constraints are derived from the result 
of Theorem 1 as follows. Assuming a most general instance t satisfying the uni- 
fication constraint we abstract each to an abstract variable also named 

N. This variable denotes the set of possible labels of the non-terminal N. We 
also let “©” replace “U” in abstract constraints. This is done mainly because our 
abstract operations deal with abstract constraints literally and do not attach to 
the binary combinator “©” any other meaning than prescribed by ACIl-axioms 
of Equation (5). The resulting set constraints reflect the relations between sets of 
concrete variables corresponding to dependent non-terminals of the type gram- 
mars, i.e. classes of variables which can interfere during the program execution. 
Abstraction of Program Constraints Function cri, defined below, maps 
constraints of the form X = Y to corresponding set constraints. We assume we 
are given the partition = { Wfl, , . . . } of non-terminals of the grammar 

Gn defining the type of terms satisfying the constraint and the set of unreachable 
non-terminals Wj, as defined by Equation (4). 



a^{C) 




« 0 ^ i 




U { iV « 0 I A G IT 0 } (6) 



Example 5. Consider the abstraction of the constraint B = C from the first rule of 
concrete “append” (Figure 1). Assume that B and C are lists with the types defined 
as La — > nil \ cons{EA, La) and Lb nil \ cons{EB, Lb)- Here we assume that Ea 
and Eb derive all possible terms thus, effectively providing the “any” type of elements. 
The grammar defining the intersection is: {Lb,Lc) nil | cons((As, Ac), {Lb , Lc))- 
Each of (Lb,Lc) and (Eb,Ec) forms an independent partition of the state space 
of this grammar. Thus, application of <ti of Equation (6) to the constraint produces: 
{Lb ~ Lc, Eb ~ Ec} ■ Note that the set IV0 is empty in this example. 



The abstraction of constraints in the form X = f(Vi , . . . , W) is almost the same 
as for X = y. In addition we take into account the fact that only bound terms 
can satisfy the constraint. Thus, for any term t satisfying the constraint we have 
({Sf,t) = 0, where Sf is a starting symbols of the right-hand side grammar. 
The function of abstraction CT 2 is defined for this case as: 



^2iC)=ai{C) U {Sf « 0} (7) 

Example 6. Consider the abstraction of the constraint A= [X| A] from the second rule 
of concrete “append” (Figure 1). Assume that A and D are lists defined respectively by 
the grammars La —* nil | cons(AA, La) and Ld nil | cons(Ao, Ld)- The intersection 
of the grammar for the right-hand side of the constraint with the grammar for A results 
in: 

Qn : {La ■) 5*cons ) ^ cons((AA, Sx), (La, I/c)) 

{La,Ld) nil I cous((Aa, Ac), (La, Ld)), 
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where Scons is a starting non-terminal of the grammar for the right-hand side. The 
partition of states of Qn is {{{La, Scona) , {La, Ld)} , {{Ea, Sx) , {Ea, Ed)}} ■ Thus, 
(72(A = [X\D]) = {La © La « Scons © Ld, Ea^Ea^^Sx® Ed, Scons « 0}, wMch 
is simplified to {La ~ Ld, Ea ~ Sx © Ed} by substituting 0 for Scons and applying 
the idempotence and unity axioms. 

Finally, the abstraction of unification constraints is formalized as a function a 
based on the two cases of Equations (6) and (7): 

if C is in the form X = Y (8) 

if C is in the form X = f{Yi , . . . , Yn) 




Note that cr(C') constrains all non-terminals of the corresponding left-hand and 
right-hand side grammars of C. This is because each non-terminal of these gram- 
mars appears either as “reachable” , i.e. as a part of some combined non-terminal 
of the intersection, or as “unreachable”, i.e. as a member of W0. 

Program Abstraction Our goal is to obtain refined view of properties of 
program variables by considering the interaction of the corresponding compo- 
nents (non-terminals) of their associated types. Thus, the abstraction of con- 
crete literals naturally replaces each variable with the corresponding tuple of 
non-terminals. Let function oj(Q) return the non-terminals of Q in an ordered 
tuple. The abstraction of literals is then dehned as: 



6 : 

6(p(X,, ...,X„))= p{w{gx,), ■ ■ .,co{GxJ). 



(9) 



The concept of abstraction of literals and unification constraints is naturally 
lifted for abstracting programs. A set logic program is obtained by applying 6 
to all literals and a to all unification constraints. The example of abstraction of 
“append” into a set logic program is shown in Figure 3. 

In Section 3 we assume that all rule heads and calls corresponding to a predi- 
cate name p/n G II have the same type. Thus, all abstract literals corresponding 
to p/n have the same form. This is important for evaluating semantics of ab- 
stract program since the corresponding parameters, i.e. tuples of non-terminals 
can be unified directly on the syntactic basis. 

The Abstract Domain of Set Logic Programs The abstract domain is 
formalized as a lattice Type(X) = {p{B®), C), where B® is a set of constrained 
abstract literals in the form: tt ^ pi A • • • A cpn- The mapping from concrete 
literals to abstract literals is provided by a®: 



a® : Be -> B^ 

a®i[p{Xi . . . , A„) ^ Cl A • • • A C^]) = 
= . . . , w(fo„)) 



f\ pA---A f\ p 

ipGcr{Ci) ip&a-(Cm) 



( 10 ) 
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append (A, B,C) 
A = [] , 

B = C. 



append({LA, Ea), {Lb, Eb), {Lc, Ec)) '■ ~ 
La -9, Ea~9, 

Lb ~ Lc , Eb ~ Ec ■ 



append (A, B,C) 

A = [XID] , 

C = [XIE] , 
append (D,B,E) . 



append({LA, Ea), {Lb, Eb), {Lc, Ec)) ■ ~ 
La ~ Ld , Ea ~ Ex © Ed , 

Lc ~ Le , Ec ~ Ex © Ee , 
append({Lo, Ed), {Lb, Eb), {Le, Ee)) ■ 



Fig. 3. Abstraction of append to set logic program 



Finally the Galois insertion between the p{Bc) and p(S®) is provided by the 
following pair of abstraction and concretization functions: 



a : p{Bc) ^ p(S®) 7 : P(S^) ^ P{Bc) 

a{I) = { a®(a) \a£l} 7 (J) = U { I ^{1) C I } 



5 Groundness Analysis of Typed Logic Programs 



Groundness is probably the best-understood and most developed application of 
abstract analysis of logic programs. Most of the known optimizations found in 
compilers of (constraint) logic programming languages require some approxima- 
tion of groundness to operate. 

The best-known method of groundness analysis of logic programs consists 
in approximating groundness dependencies using the domain of positive boolean 
formulas called Pos. This method is proposed in [14]. Without loss of generality 
the abstraction of unification constraint t\ = t 2 is defined by the following func- 
tion aposi 

apos : C Pos 
Q:pos([il = ^2]) = 



A " A 



W 



( 12 ) 



I V^Gvars(ti) 



t^Gvars(i2) 



Thus, the abstraction of ground ti or ground t 2 results in T (true) on the corre- 
sponding side of the formula. The notion of Pos-based groundness abstraction is 
naturally lifted for all syntactic objects such as constrained literals, rules and pro- 
grams. The semantics of a GLP(B) program resulting from program abstraction 
provides a correct approximation of groundness dependencies of the original pro- 
gram. The abstract domain for groundness analysis is thus formalized in terms 
of (sets of) Pos-constrained literals ordered by logical consequence. 

Example 7. The abstraction of “append” for Pos-based groundness analysis. 
append(A, B, C) A T , B^C. 

append) A, B, C) A^XAD, C^XAE, append(B, B, B) . 

The bottom-up evaluation of this program results in the well-known groundness ap- 
proximation: append(A, B,C):~ C ^ A A B. Note that this result is less precise than 
the result for typed “append” shown in Section 1. 
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It’s clear that given type descriptions we can adopt a more refined view 
of groundness than in the untyped case. Namely, groundness of a term can 
be expressed in terms of boundness of all non-terminals of the corresponding 
grammar. If we can prove, for instance, that for some non-terminal N and for 
any t satisfying the constraint we have C(iV, f) = 0, it means that the subterm 
corresponding to N is always instantiated. Consequently proving that C{N,t) = 
0 for any N means that all terms satisfying the constraint are ground. The 
following two dehnitions formalize the concepts of boundness and groundness: 

Definition 6 (Boundness). Non-terminal N of the grammar Qy assoeiated 
with a variable V is bound by a substitution 9 if ({N,V 9) = 0. 

Definition 7 (Groundness). A variable V is ground under a substitution 9 if 
all non-terminals of the associated grammar Qy are bound by 9. 

The domain for groundness analysis of typed logic programs is called Type(Pos). 
It is a proper abstraction of the generic domain Type(X) presented in Section 4 
obtained by application of Opos of Equation (12) to ACIl-constraints of a set 
logic program. As an example, the application of Opos to the abstract “append” 
shown in Figure 3 results in the program shown earlier in Figure 1. 

The semantics of the resulting abstract CLP(B) program is then evaluated 
either in a top-down or a bottom-up way. Thus, the approximation of boundness 
of a program is obtained by its abstraction into a set logic program followed by 
direct application of Pos-based groundness analysis. 

Clearly, the analysis in Type(Pos) is at least as precise as the analysis in 
Pos. We formalize this relation showing that given a description in Type(Pos) 
we can always “abstract away” the types and get a description in Pos domain. 
In other words, we are showing that Pos is a proper abstraction of Type(Pos). 
Intuitively this claim is supported by the fact that groundness of a program 
variable V can be expressed as Pos-formula V ^ /\ngWv '''’ti^re Wy is the 
set of non-terminals of the type grammar Qy . 

Theorem 3. Pos is a proper abstraction o/Type(Pos). 

Example 8. The groundness description of typed “append” shown in Section 1 can be 
mapped onto the original program variables as 

append(A, B,C) La ^ T, Lb ^ Lc, Ec ^ Ea A Eb, 

A > La a Ea^ E > Lb /\ Eb^ C > Lq A Ec- 

This description implies the standard result for untyped “append” . 



6 Sharing Analysis of Typed Logic Programs 

Two or more variables in a logic program are said to share if in some execution 
of the program they are bound to terms which contain a common variable. The 
information about sharing of program variables provides the basis for many 
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optimizations, such as occur check reduction [20] or elimination of run-time 
dataflow checks in and-parallel execution [9] . 

One of the more widely applied sharing analyses reported in the literature is 
the so called set-sharing analysis based on Sharing domain originally proposed 
by Jacobs and Langen [11]. The alternative domain for set-sharing analysis is 
recently presented in [3]. This domain denoted by Sh® is isomorphic to Sharing 
and based on set expressions. Sharing descriptions are obtained by abstracting 
original programs into set logic programs and evaluating their meaning using 
standard top-down or bottom-up semantics extended with ACIl-unification. 

In this work we show how both both Sharing and Sh® can be upgraded with 
type information of Type(X) domain resulting respectively in Type(Sharing) and 
Type(Sh®). It turns out similarly to the case of groundness analysis that the 
abstract operations of Sharing and Sh® can be applied to set logic programs 
resulting from Type(X) abstraction. Moreover, sharing analysis based on Sh® 
can be applied directly to a result of Type(X) abstraction because of the same 
syntax used in both domains. 

Similarly as groundness can be viewed as a combination of the corresponding 
boundness dependencies, set-sharing between program variables can be viewed as 
a combination of aliasing of labels of corresponding non-terminals. The following 
two definitions formalize the concepts of aliasing and sharing: 

Definition 8 (Aliasing). Non-terminals Ni . . . Nn of the respeetive grammars 
Gi ■ ■ - Gn associated with variables V) ... 14, are aliased by a substitution 0 if 
C(iVi,4i0)n---nC(iV„,i40) 4 0. 

Definition 9 (Sharing). Program variables Vi . . . 14 share under a substitu- 
tion 9 if there is a set of non-terminals Ni . . . Nn of the respeetive grammars 
Gi ■ ■ - Gn aliased by 9. 

Example 9. Consider the bottom-up sharing analysis of abstract “append” shown in 
Figure 3 using Sh®. The result is: 

append((LA, Aa), (Ls, Ab), (ic, Ac)) La ~ 0, Lb~Lc, Ec~Ea®Eb- 

showing that La is gronnd; Lb and Lc can share; Ec can share with each of Ea and 
Eb, but Ea and Eb are independent. The analysis based on Sharing domain can also 
be applied producing the same (upto isomorphism) result. The abstraction in Sharing 
treats terms as sets of variables and thus can be applied to set constraints. The result 
of the analysis in Sharing is naturally r/> = {0, {Lb, Lc} , {Ec, Ea} , {Ec, Eb}} ■ 

Note that the information computed in Example 9 approximates possible aliasing 
between the labels of the corresponding non-terminals. The information about 
actual sharing of program variables can be extracted by projecting the aliasing 
back on the type description. For instance, variables A and C of “append” can 
share because the elements of the lists can be aliased. Variables B and C can 
share because of two possible reasons: the structures can be aliased, provided 
by the aliasing of Lb and Lq or the elements can be aliased, provided by the 
aliasing of Eb and Ec- In general, if we adopt the syntax of Sh® , the information 
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about sharing of the original variables can be captured by introducing new set 
constraints in the form V « iVi 0 • • • © Nk, where is a program variable and 

. . . Nk are non-terminals of the corresponding grammar Qy Thus, similarly 
to the case of groundness analysis we can show that the analysis in Type(Sh®) 
is at least as precise as in Sh®. The similar result for Sharing follows by the 
isomorphism. 

Theorem 4. Sh® is a proper abstraction o/Type(Sh®). 

7 Related Work and Conclusion 

We briefly compare the approach proposed in this paper with some previous 
works presenting abstract domains based on regular types. 

Janssens and Bruynooghe present in [12] a framework for program type and 
mode analysis of Prolog programs based on type graphs. The abstract domains 
based on rigid types and integrated types are capable of inferring types and modes 
of a program. The later domain can track freeness as an additional mode, thus 
significantly improving the precision of analysis for programs manipulating par- 
tially instantiated structures. The work of Mulkers et al. [16] applies the frame- 
work of [12] for tracking liveness of Prolog structures. The abstract domain 
developed in this work models the execution environment of a predicate using 
type graphs and special arcs representing structure sharing. In Bruynooghe et 
al. [1] the framework of [16] is further extended and applied to liveness analysis 
of statically typed languages such as Mercury. 

The work of Van Hentenryck et al. [8] presents the systematic approach to 
the construction of abstract domains using the generic domain Pat (7?,). In par- 
ticular, authors describe how the domain of type graphs Type can be integrated 
into Pat (7^) producing Pat (Type). The resulting domain provides type and mode 
inference similarly to the domain of Janssens and Bruynooghe [12]. 

The main difference of our approach from the mentioned works is in the 
way we deal with regular types. In all cited works the abstract representation 
includes regular types as a component. Abstract operations presented in these 
works normally involve complex and costly manipulations with type graphs dur- 
ing the analysis. In contrast, our approach fully handles the type descriptions on 
the stage of program abstraction, i.e. by type-based abstract compilation into 
set logic programs. The most similar approach in a technical sense is that pro- 
posed by Naish [18]. In this work the problem of modes validation of a typed 
and moded logic program is reduced to checking the entailment on multiset 
constraints composed from parameters of polymorphic types. 

We have presented an approach to analysing typed logic programs by map- 
ping to a set logic program. It is a straightforward syntax-directed translation 
which can increase the size of the program by a factor df , where d is the largest 
number of nonterminals in a grammar, although in practice it is usually linear. 

A practical advantage of the approach is that the type-based analyzer does 
not need to manipulate automata or graphs during the analysis. Instead, the 
actual analysis which comes after the type-based abstraction can be delegated 
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to the existing analyzers thus rensing their expertise together with their code 
and optimizations. 

An obvious direction for the future research is to extend our approach to 
directly handle parametric polymorphism in types. Another direction for the 
research consists in formalizing and extending the class of abstract domains 
that can be upgraded with type information using our method. Here we show 
that two important abstract domains in logic program analysis, Pos and Sharing, 
fall into this class. 
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Abstract. An abstract domain for non pair-sharing and freeness analy- 
sis of logic programs has been recently developed by using the automatic 
technique of linear refinement. W.r.t. previously available domains, it 
can be used for abstract compilation, which allows a modular and goal- 
independent analysis of logic programs. In this paper, we describe our 
implementation of an analyser which uses that domain. Sometimes, we 
have sacrificed precision for efficiency. We evaluate it over a set of bench- 
marks and we compare the results with those obtained through a goal- 
dependent analysis. Not surprisingly, our goal-independent analysis is 
slower. However, it is almost always as precise as the goal-dependent 
one. To the best of our knowledge, this is the first goal-independent im- 
plementation of sharing analysis based on abstract interpretation, as well 
as the first implementation of a linearly refined domain. 



Keywords: Abstract interpretation, domain theory, linear refinement, linear logic, 
logic programming. 



1 Introduction 

Pair-sharing analysis [1, 16] determines those pairs of variables which, in a given 
program point, can be bound to two terms which share some variable. It is a 
particular case of set-sharing analysis [12]. In set-sharing analysis, indeed, sets of 
variables are considered, and not just pairs. It is useful for avoiding occur-check 
[16] and for automatic program parallelisation [12,15]. As stressed in [1], pair- 
sharing information is actually needed in program analysis and transformation, 
set-sharing information being redundant w.r.t. pair-sharing information. 

Freeness analysis [4, 15] determines those variables which are always bound 
to a variable in a given program point. It is useful for optimising unification, for 
goal reordering and for avoiding type checking. It is well known that performing 
sharing and freeness analysis together improves the precision of both [12, 15]. 

When the fixpoint computation is based on a compositional definition, the 
{i 4- l)-th iteration can re-use any intermediate results already computed during 
the i-th iteration that are known not to change across iterations. Such results 
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are usually the denotations of some program parts which do not contain recur- 
sive procedure calls. Therefore, these parts can be replaced by their denotation 
and the fixpoint computed on this modified (partially compiled) program. This 
technique is traditionally known as abstract compilation [5, 11], since it is an ap- 
plication of abstract interpretation [9] where a program is iteratively compiled 
to its abstract denotation. This leads, in general, to a more efficient computation 
of the abstract fixpoint. Moreover, modular analysis is allowed. This means that 
procedures or libraries can be analysed separately, and their analyses can then 
be combined to obtain the analysis of a large program. 

Linear refinement [10] is a technique for systematically improving abstract 
domains for program analysis. It has been defined as a slight generalisation of 
Cousot’s reduced power operation [8]. Given a basic abstract domain represent- 
ing just the property of interest and a concrete operation Kl (in the case of logic 
programming, unification) the new refined domain is constructed, and allows 
us to define an abstract operation which is more precise than that of the basic 
domain. This is achieved by enriching the basic domain with linear logic impli- 
cations i -> o representing the propagation of the abstract property of interest 
through the concrete operator Kl. Namely, if the abstract property i holds for 
the input of the operator Kl then the abstract property o holds for its output. 
In this way, the development of new domains becomes almost automatic and we 
can define the denotation for a procedure as a function from abstract properties 
of the input to abstract properties of the output. Thus, static analysis can be 
applied even if the source code of some procedures is not known (which can be 
the result of some copyright policy), provided that its abstract denotation is 
available. 

In [13] an abstract domain for non pair-sharing and freeness analysis has 
been developed through linear refinement. It is more precise than the traditional 
domain of [12] and correct abstract operators have been explicitly defined. How- 
ever, no experimental results are provided. Since the abstract operations are not 
optimal, the usefulness of the domain was left unclear. 

Our contribution is the implementation of the domain of [13], which is the 
first implementation of a goal-independent sharing and freeness analysis of logic 
programs based on abstract interpretation, as well as of a linearly refined domain. 
Note that the traditional domains for groundness did exist before it became clear 
they could be obtained through refinement. Beyond the implementation, this 
paper contains a piece of theory about reduction rules, necessary for an efficient 
analysis, and which can be tuned in such a way to avoid any loss of precision. 

1.1 Related Works 

Almost all works about sharing analysis are not amenable to abstract compi- 
lation and have been developed without any automatic technique like linear 
refinement. To the best of our knowledge, only [4, 6, 7] provide abstract domains 
for sharing analysis which can be used for abstract compilation. The domain 
in [4] models sharing, freeness and groundness. It is not based on abstract in- 
terpretation. Its authors claim that its precision is no more than that of the 
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Sharing x Free domain of [12]. An implementation exists. The domain in [6] is 
isomorphic to the Sharing domain of [12]. The domain in [7] is isomorphic to the 
domain Pos for groundness analysis. Since in both cases the authors provided an 
abstract unihcation algorithm over the abstract domain only (in contrast with 
an abstract unihcation algorithm between an element of the abstract domain 
and a concrete substitution, like in [12]), abstract compilation is allowed in both 
cases. However, the domains in [6] and [7] induce abstraction maps which are too 
coarse for practical applications. Namely, those maps cannot distinguish between 
concrete substitutions like {x = y} and {x = f(y,y)} (as implied by Equation 
(7) of [6] and Observation 4.1 of [7]). However, those substitutions must be dis- 
tinguished in order to provide decent precision, as shown in Example 8 of [13]. 
Other sources of imprecision are shown by Examples 4 and 5 of [13]. Some of 
those problems can be solved by adding freeness and linearity to the abstract 
domain, but we are not aware of any implementation of the domains in [6] and 
[7] coupled with freeness and linearity. 

2 Preliminaries 

We denote by p(S') the powerset of a set S, by ffS its cardinality and by pf{S) 
the set of all hnite subsets of S. 

Given a set of variables V and a set of function symbols E with associ- 
ated arity, containing at least a symbol of arity 0, we dehne terms(Z', V) as 
the minimal set of terms built from V and E, i.e., V C terms(A', E) and if 
ti,...,tn G terms(I7, E) and f" G E, then f(ti, . . . ,t„) G terms(I7, E). We de- 
note by vars(t) the set of variables which occur in a term t. When vars(t) = 0 
we say that t is ground. If a; is a variable, E U a; means E U {a;} and E \ a; 
means E \ {a;}. The set of idempotent substitutions 0 (dom(0) U rng(0) C E and 
dom(0) n rng(0) = 0) is denoted by Oy- 

Let V be an infinite set of variables and E G p/(V). We dehne the set 
Cv = Pf{t^ — I t^,t'^ G terms(I7, E)} of Herbrand eonstraints. Let W be an 
inhnite set of variables disjoint from V. For each E G p/(V), we have the set of 
existential Herbrand constraints 

W G p/(VV), c G Cvuw and there exists 1 
9 G Ovvjw s.t. rng(0) C E and c9 holds J 

Here, V are called the program variables and W the existential variables, which 
are a formalisation of the unnamed variables of Prolog. The condition about the 
existence of 9 such that c9 holds, means that we consider satishable constraints 
only. 

Four operations, called conjunction, restriction, expansion and renaming, are 
dehned over Hy. 

Definition 1. We define : Hy x Hy Hy, restrict^'^ : Hy i-^ Hy\n with 
n G V, : Hy i— > Hy^j, with x ^ V, and renameffEn ■ Hy ^ Hf^y\x)un, 
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with X gV and n as^ 



{3W2C2) = 

restrict^'^ {'^wc) = 
expand^'^ i^wc) = 
rename^Xn(3wc) = 



I ^WiUW 2 mgu(ci U C 2 ) if mgu(ci U C 2 ) exists, 
1 undefined otherwise 

3wuNc[N/n] with N eW\W, 

3\vc , 

3w{,c[n/x\) . 



Note that in the definition of -k^'' we put the constraint in normal form through 
the Martelli and Montanari unification algorithm [14]- The other operations are 
closed on the set of existential Herbrand constraints in normal form. 



Our concrete domain is the collecting version [9] of Hy, i.e., the lattice 
(p(ffv), n, U, iJy, 0). The operations on Hy are point-wise extended to p{Hy). 
The new operation S2) = S\\J S2 is defined. It is used to merge the 

results of different branches of execution. 



3 Non Pair-Sharing and Freeness Analysis 

We briefly recall the definition of the abstract domain for non pair-sharing and 
freeness described in [13]. Its abstract elements are sets of arrows. 

Definition 2. Given V € p/(V), we denote by V 2 the set of unordered pairs of 
elements of V. We define ShFy = p(V U V 2 ) as the domain used to express the 
freeness of variables and the non-sharing of pairs of variables. We define Absy = 
p{ShFy X (V U V 2 )). We write the elements 0 /V 2 as {vi,V 2 ), with {v\,V 2 } C V 
and a pair ({Zi, . . . , In}, r) G Absy as h ••• In ^ r, for n > 0. The dimension 
dim(s) of s G ShF is its cardinality. If A G Absy, dim(xl) = 

For instance, the object x{y, z) G ShFy means that x is free and that y and ^ 
do not share any variable. The arrow li ■ ■ - In => r represents the set of existential 
Herbrand constraints which, when unified with a constraint satisfying h ■ ■ ■ In 
(i.e., whose freeness and non pair-sharing properties are consistent with those 
expressed by Zi • • • Z„), give a result satisfying r. 

We can approximate the operations of Definition 1. Entailment and tauto- 
logical arrows are defined in [13]. Roughly speaking, I G ShFy entails I' G ShFy 
when every existential Herbrand constraint satisfying I satisfies I' , i.e., its free- 
ness and non pair-sharing properties, when consistent with those expressed by I 
are also consistent with those expressed by I'. For instance, we have that x{y, x) 
entails (y,x) and x, and that (x,x) entails (x,y) (since (x,x) means that x is 
ground). A tautological arrow is an arrow which is satisfied by every constraint. 

^ In the definition of we assume Wi nIF 2 = 0, since a constraint 3wc is equivalent 
to 3 vv'c[IFYIF], with W' made of fresh variables. Similarly, different choices of N 
in restrict)^'^ lead to equivalent constraints. 
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Definition 3. LetAi,A 2 G Absy- LetT be made of tautologieal arrow?. Then 



Ai A2 



h 



* * ^ 



ri ■ ■ - rn ^ r G A2UT, k=^ r'^ G AiUT 
and r[ entails ri for i = 1, . . . ,n, or 
Ti - ■ -rn=> r G Ai\JT, ^ r ' G A2 U T 

and r ' entails ri for i = 1, . . . ,n 



In our implementation, in Definition 3 we use T = {(u,u) (u,u) | u G V}. 

Example 1. In Definition 3 , let T = {}, D = {x,y,z} and 



Ai = {xy X, {x, y){x, z) ^ {x, y), {x, x) {z, z)} , 
A 2 = {x(x,y) ^ X, ^ (y,y)} ■ 



Then 

Ai A 2 = {xy{x, y){x, z) ^ x, ^ {y, y)} . 

Note that we do not obtain the arrow {{x, x) (z, z)}, since the set T is empty. 
But this arrow must hold for Gli since it holds for A\ and groundness 

dependencies cannot be lost. By using T A {(u,u) =i> {v,v) \ v G V} we would 
include that arrow in the conjunction. 



Definition 4. Let V G p/(V) and n G V. Let X = {n} U {{v,n) | u G V} and 
A,Ai,A 2 G Absy. We define 



restrict 



Abs\, 



{A) = \l\X^r 



I ^ r G A, (n, n) ^ I, 
r ^ n and r ^ (n, v) for every v gV 



If X G V, n and A G Absy, we define 



rename 



Abs\ 



(A) = yl[n/a:] . 



Finally, we define 

U^^^^{Ai,A 2) = {hh ^r\h^rGAi, I2 ^ r G A2} . 
Example 2. Let V = {x, y, zj and 

A = {xy=A X, xy ^ y, {x, x) {y, z), {y, z){x, y){x, z) {y, z)} . 



Then 

restrict^^®'" (A) = {y ^ y, {y, z) ^ {y, z)} . 

For the expansion, we use a distinguished variable ?i G fo which stands for all 
the variables which do not occur in the Herbrand constraints. In order to compute 
expand,^^®'^(yl), we substitute x for ?i in A. Since non pair-sharing is a property 
of pairs of variables, we wish to know how this new x behaves in conjunction 
with the distinguished variable itself. Thus we use two distinguished variables 
?i and ?2. By using the abstraction map (Definition 6) with {?i,?2} C V, we 
introduce these variables in the constraints. 

The larger T is, the more precise jg 



2 
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Definition 5. Let V € p/(V) and a; G V \ F. Let {?i, ? 2 } C V and A G Absy- 
We define 

expand^''^'"(A) = A U {^[a;/?i] [?i/? 2 ] =5> r[a:/?i][?i/? 2 ] \ I ^ r G A} . 
Example 3. Let V = {x, y, z} and 



A={?i(x,?i) 



?1,(?1,X)(?1,^)(?1,?2) 



xyz 



z}. 



Given n G V\V we have 



expand;^'''’'" (A) = | 



xyz ^ z, n{x, n) n, (n, x){n, z){n, ?i) =^> (n, ?i), 1 
?1(X,?1)^?1,(?1,X)(?1,^)(?1,?2)^(?1,?2) / ■ 



We show here how to compute an approximation of the abstraction map. It 
considers separately the information of groundness, non pair-sharing and freeness 
contained in a binding. A substitution is then abstracted by combining through 
^Absv abstraction of every binding of which it is composed. 

Definition 6. Let V G p/(V), v gV and t G terms(I7, V). We define 

(v = t)= = t)U aXshiv = t)U a)fiv = t) , 

where o^^., and are defined below. We write t{vi, . . . ,Vn) for t if 

vars(t) = {vi, . . . ,Vn}. If n — 0 then t{vi, . . . ,Vn) is ground. Variables with 
different names are different variables. 



a^riv = t(vi, . . . ,Vn)) = U 
v'GV 



{Vi,Vi) - ■ ■ {Vn,Vn) ^ {v,v'), 

(V,V) ^ {V1,V),...,{V,V) ^ (Vn,V) 



e^nshix t) 
\x = t(v,v',Vl,...,Vn)) 

<xffl\x = t{v,Vl,...,Vrf)) 
= t) 






^{v,v'}CVQ^ffl\x = t) 

{} = = ^') t' ground 

{x{v,v) ^ (v,w')} 

{(«', v){v', Vl)--- {v, Vn) ^ {v, v)} 
t{vi, . . . , Vn) non ground 

( {v',v){v',x){v',vi) ■ ■ ■ (v',Vn) ^ (v',v), 
\ {v' , v){v' , x)x ^ {v' , v) 

{(w,v') ^ (w,v')} t ground 

{ (v,v'){v,x){v,vi) ■ ■ ■ (v,Vn) ^ (v,v'), 
{v,v'){v',x){v',vi) ■ ■ ■ {v',Vn) ^ iv,v'), 
{v, v')(v, x)(v', x)x ^ (v, v') 



t{vi , . . . , Vn) non ground 
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— f) — — f) 

Ofriv = x) = {vx ^ v} = Ofrix = t{v , Vl , . . . , Vn)) 
a}r(v = t(vi,. . . ,V„)) = {} t{vi, . . . ,v„) 

a}r{x = y) = {v{x,v){v,y) ^ v,vxy ^ w} 
a'frix = . . ,V„)) = {vx{x,v) ^ V, v{x, v){vi,v) ■ ■ ■ {Vn, v) ^ t)} 

t{vi, ...,v„)^V. 

We can compute the abstract information contained in an abstract constraint, 
i.e., the set of variables which are free and the set of pairs of variables which do 
not share in any existential Herbrand constraint belonging to the concretisation 
of the abstract constraint. 

Definition 7. Given V € p/(V), we define freey ■ Absy p(^) and nshy : 
Absy I— > V 2 as 

freey{A) ={vGV\1^vgA and v'{v', v') % I for any v' G V} , 
nshr/(yl) = {(fi,f 2 ) G V 2 \ I ^ {vi,V 2 ) G A and {v,v) ^ I for any v gV} . 

4 Implementation 

We describe now our prototypical implementation^ of the domain of Section 
3. We did not aim at efficiency, though much care has been taken to avoid 
the explosion of the computational cost of the abstract conjunction operator 
(Dehnition 3). 

Constraints are manipulated by C procedures, while the normalisation, ab- 
straction and fixpoint computation phases (see below) are written in Prolog. The 
choice of C as implementation language for the constraints is a consequence of ef- 
ficiency considerations. Indeed, constraints are represented by arrays of bitmaps. 
Every basic token of information, i.e., the freeness of a variable or the non-sharing 
of a pair of variables, is associated with a bit position. Elements of ShFy (Deh- 
nition 2) are then implemented as strings of bits. 



4.1 Normalisation, Abstraction and Fixpoint Computation 

We describe the three phases of our analysis, normalisation, abstraction and 
hxpoint calculation of the abstract s-semantics for computed answers [3] (a call- 
pattern or resultant semantics could be used here), by using the traditional 
member/2 program as a running example: 

member (X , [X I Xs] ) . 

member (X, [Y I Ys] ) : -member (X,Ys) . 

® Downloadable at http://www.di.unipi.it/~amato/papers/flops01.tgz. 
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Normalisation transforms a program in such a way that procedure calls are 
made only in their most general form, i.e., with variables v(0), v(l), and so on, 
as arguments. Moreover, the structure of the program (disjunctions, conjunc- 
tions, expansions and similar) is made apparent, which simplifies the subsequent 
fixpoint iteration. For instance, the normalisation of member/2 is 

member (2) 

rename(v(16) , v(0) , rename (v(17) , v(l), or( 

restrict(v(18) , bi_eq(v(17), [v(16) I v(18)] ) ) , 
restrict(v(20) , and( 

expand(v(16) , restrict (v(19) , bi_eq(v(17) , [v(19) I v(20)] ) ) ) , 
expand(v(17) , rename(v(0), v(16) , rename(v(l), v(20) , 
call (member (2) ) ) ) ) 

)) 

))) 

The program has been compiled in a code which contains calls to the abstract 
operations of the domain, as well as built-in’s, like bi_eq, which unifies two terms, 
and procedure calls, like call (member (2) ) , where 2 is the arity of the procedure. 
This preliminary transformation has the advantage of keeping the set of variables 
used for the analysis of a given program point as small as possible. For instance, 
if a variable is not used in a constraint, then it will be added (through expand) 
after the analysis (i.e., the abstraction) of the constraint. See the case of v(16) 
and v(17) in the normalisation of member/2 above. If a variable is not used 
after a conjunction, then it can be removed (through restrict). See the case 
of v(20) in the normalisation of member/2 above. This reduces the complexity 
of the analysis, since the abstract operations have computational complexities 
which are proportional to the dimension of the elements of the abstract domain, 
and this dimension is in its turn proportional to the number of variables used. 

Note that the normalisation phase above is not abstract compilation. Instead, 
abstract compilation substitutes the built-in’s with their abstract behaviour, i.e., 
a constraint of the abstract domain. In the case of bi_eq it applies the abstraction 
map of Definition 6. Moreover, it applies partial evaluation when the operands 
of an abstract operation are known (i.e., if they do not contain any procedure 
call), by substituting the operation with its result. In our case, we obtain 

member (2) 

rename(v(16) , v(0) , rename (v(17) , v(D, or( 
abs (177072) , 
restrict(v(20) , and( 
abs (203050) , 

expand(v(17) , rename(v(0), v(16) , rename(v(l), v(20) , 
call (member (2) ) ) ) ) 

)) 

))) 

An element of Absy is written as abs(iV), N being the pointer in memory 
where the constraint is stored. Indeed, as we have said, constraints are manipu- 
lated by C procedures. 
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The calculation of the abstract fixpoint is just an iterated depth-first eval- 
uation of the abstract program, by using the operations of Section 3. The call 
graph of the program is used. Namely, if a procedure p is called by a procedure 
q but not vice versa (even through intermediate procedures), the denotation of 
p is computed first, and that of q later. In the case of member/2, this machinery 
is of no help. 

Even for a procedure as simple as member /2, our abstract analyser would not 
reach the abstract fixpoint in a reasonable time, since the computational cost of 
the analysis explodes. We show now how to obtain a reasonable performance. 

4.2 Reduction Rules and Widening 

Since several elements of Absy may have the same concretisation (y^ep is de- 
fined in the proofs appendix) and the computational complexity of the abstract 
operators of Section 3 depends on the dimension of their operands, we wish to 
use the elements of Absy of smallest dimension. This is the goal of reduction 
rules. 

Definition 8. A reduction rule is a family of maps {py}y^pf(v) such that, for 
every V G pf{V), 

i) py : Absy 1 -^ Absy, 
a) dim(/9y(yl)) < dim(A) and 
in) lRep{pv{A)) = '^Rep{A) for every A e Absy. 

The last two conditions say that a reduction rule reduces the dimension of a 
constraint without losing any information. Though it can be shown that not all 
the operations of Section 3 are monotonic w.r.t. dim, our evaluation (Section 5) 
suggests that reduction rules are useful in practice. If we apply a reduction rule 
after every abstract operator. Definition 8 guarantees that we obtain a correct 
result. The following condition entails that we do not lose any precision, which 
was not obvious, since the abstract operators are not optimal. 

Proposition 1. For V G p/(V) and Ai,A 2 G Absy, let Ai A A 2 if and only if 
for every I 2 r G A 2 there is li ^ r G Ai with 

h C I 2 U {(f, u') \v,v' &V, V ^ v' and (v, v) G I 2 } ■ 

Every reduction rule p which is reductive w.r.t. ^ (i.e., p{A) A A for every 
A G Absy) does not introduce any loss of precision. 

We show now two examples of reduction rules which are reductive w.r.t. 

Proposition 2. Let p^ = {Py}y^pf{v), where 

there is no I' ^ r G A s.t. 

V cl A {(u, v') \v,v' &V, V ^v' and (v, v) G 1} 

for any V G p/(V) and A G Absy. Then p^ is a reduction rule and is reductive 
w.r.t. <. Moreover, it is possible to prove that f^{A) = P|{X C A | A* ^ A}, 
i.e., p^(A) is the smallest set of A to precede A w.r.t. 



Pvi^) = <l^r e A 
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Example 4- Let V = {v,x,y,z} and 

A = {x{x,y){x,z){x,v) ^ {x,v),x{v,v) ^ {x,v),xy y,x(x,v) ^ (a;,t;)} . 
Then 

Pv{A) = {xy y, x{x, v) ^ {x, w)} . 

Proposition 3. Let = {Pv}v&pf{v), where 

Pvi^) = {^ \ ({(^) 'v') \v,v'&V, V ^v' and (v,v) G 1} ^ r) \ I ^ r G A} 

for any V G p/(V) and A G Absy- Then p^ is a reduction rule and is reductive 
w.r.t. 

Example 5. Let V = {n, x, y, z} and 

A = (x(x, y){y, y){y, z){x, z) ^ {x, z),xy => y, y{y, z){z, z){v, v) => y} . 
Then 

Pv(^) = {x{y, y){x, z) ^ (x, z), xy => y, y{z, z){v, v) ^ y} . 

The efficiency of the analysis can be obviously improved by removing some 
arrows from the elements of Absy, possibly introducing some imprecision, like 
with every widening operation [9]. In our implementation we use syntactical 
equality for the entailment test of Definition 3, which means that some arrows 
allowed by the theory are not generated by the implementation. 

4.3 The Result of the Analysis 

By using the techniques of Subsection 4.2, our analyser computes the following 
denotation for member /2: 

?1, (al,?l), (a0,?l) ,(a0,al)=>?l 
?l,al, (al,?l)=>?l 

(?1,?2) ,(al,?l) ,(a0,?l) ,(a0,al)=>(?l,?2) 

(? 1 ,? 1 )=>(? 1 ,? 1 ) 

(al,?l) ,(a0,?l) ,(a0,al)=>(al,?l) 

(al,al)=>(al,al) 

al,a0, (a0,al)=>a0 

(al,?l) ,(a0,?l) ,(a0,al)=>(a0,?l) 

(al,al)=>(a0,?l) 

(aO , aO) => (aO , aO) 

(al , al) => (aO , aO) 

The variables aO and al are the two argument positions of the procedure. 
Beyond simple groundness dependencies, note that the analyser concludes that 
al,a0, (aO,al) aO. Indeed, if member/2 is called with two different free vari- 
ables, then the freeness of the first variable cannot be lost. Note that the simple 
freeness of al and a2 is not judged enough to this purpose. Indeed, a call like 
member (X,X) binds X to the term [X| J if the occur-check is not applied. If the 
occur-check is applied, the freeness of al and a2 would be enough. 
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Benchmark 


Bytes 


Prepr. 


Fix. 


Conj. 


Others 


Shell 


ackermann.pl 


139 


0.06 


0.10 


35.0% 


7.2% 


57.8% 


append.pl 


62 


0.03 


0.52 


77.5% 


6.9% 


16.5% 


eliza.pl 


1400 


0.42 


2.20 


70.1% 


6.0% 


23.9% 


hanoi.pl 


199 


0.09 


2.91 




4.3% 


5.7% 


heapify.pl 


508 


0.16 


106.67 


99.5% 


0.0% 


0.5% 


map_coloring.pl 


419 


0.08 


0.49 


57.6% 


12.9% 


29.5% 


queens.pl 


735 


0.24 


1.01 


52.7% 


14.9% 


33.3% 


quicksort.pl 


431 


0.18 


18.45 


97.0% 


1.0% 


2.0% 


openlist.pl 


159 


0.76 


0.48 


80.3% 


10.5% 


9.2% 



Fig. 1. The analysis times. 



5 Experimental Evaluation 

We show now the behaviour of our analyser on some benchmarks. We have used 
SWI-Prolog 3.3.2 over an AMD K5 lOOMhz processor with 64Mbytes of memory, 
running Linux 2.2. The techniques of Subsection 4.2 have been applied. 

In Figure 1, for every benchmark, we report its dimension in bytes, the time 
in seconds spent in the preprocessing phase (normalisation, abstraction and call 
graph construction), that spent for the fixpoint calculation, and the relative 
computational cost of the conjunction operation (Definition 3) w.r.t. the other 
operations of the domain and the shell (preprocessor) which normalises, ab- 
stracts and computes the fixpoint. As you can see, the preprocessing time is 
always small, while the fixpoint calculation is sometimes expensive and is much 
more related to the number of variables in the clauses of the program than to 
its dimension (compare the lucky case of eliza.pl with that of heapify.pl). 
Indeed, when that number becomes large, the time spent for the abstract con- 
junction explodes, as the fifth column shows. Thus a clever implementation of 
the conjunction is welcome. 

We have compared our analyser with a goal-dependent analysis performed by 
using the Sharing x Free domain [12] inside the China analyser"^ [2]. The result is 
shown in Figure 2. The goal-dependent analysis is definitely more efficient, but 
must be re-executed for every query. W.r.t. precision, we have run some abstract 
queries with the goal-dependent analyser and we have compared the resulting 
abstract information with what we get by instantiating our goal-independent 
denotation on the queries. 

In the third column, “A” means “A free” , while “ ( A , B , C) ” means that A, B and 
C are mutually independent, and is a compact notation for (A,B) (A,C) (B,C). 
The last two columns show the results of the analysis with our analyser and 
with China, expressed in our domain. Our analyser is always as precise as China 
except for app/6, a version of append/3 for incomplete lists. 

^ We thank Roberto Bagnara for his help with this experiment. 
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Benchmark 


Predicate call 


Input constraint 


Our response 


China’s 


ackermann.pl 


ackermaim ( A , B , C) 


ABC(A,B,C) 


(A, A) 


(A, A) 


(B,B) 


(A, A) (B,B) 
(C,C) 


(A, A) (B,B) 
(C,C) 


append.pl 


append (A, B,C) 


ABC(A,B,C) 


B(A,B) 


B(A,B) 


BC(A,B,C) 


B(A,B) 


B(A,B) 


C(A,B,C) 


(A,B) 


(A,B) 


(C,C) 


(A, A) (B,B) 
(C,C) 


(A, A) (B,B) 
(C,C) 


eliza.pl 


eliza(A) 


A 


true 


true 


hanoi.pl 


hanoi(A,B,C,D,E) 


ABCDE(A,B,C,D,E) 


(A, A) 


(A, A) 


(E,E) 


(A, A) (B,B) 
(C,C)(E,E) 


(A, A) (B,B) 
(C,C)(E,E) 


heapify.pl 


heapify(A,B) 


AB(A,B) 


true 


true 


(A, A) 


(A,A)(B,B) 


(A, A) (B,B) 


map_coloring.pl 


color_map(A,B) 


AB(A,B) 


true 


true 


queens.pl 


queens (A, B) 


AB(A,B) 


(A, A) (B,B) 


(A, A) (B,B) 


(A, A) 


(A,A)(B,B) 


(A, A) (B,B) 


quicksort.pl 


quicksort ( A, B) 


AB(A,B) 


(A, A) (B,B) 


(A, A) (B,B) 


(A, A) 


(A,A)(B,B) 


(A, A) (B,B) 


openlist.pl 


nil(A,B) 


AB(A,B) 


B 


B 


cons(A,B,C,D,E) 


CDE(A,A) (B,D,E) 
(C,D,E) 


CE(A,A) 


CE(A,A) 


app(A,B,C,D,E,F) 


BDEF(A,C,E,F) 
(A,D,E,F) (B,C,E,F) 
(B,D,E,F) 


true 


DF 


list2open(A,B ,C) 


BC(B,C) (A, A) 


C(A,A) 


C(A,A) 



Fig. 2. The comparison of our analysis with that done through China. 



6 Conclusion 

We have described the implementation of a static analyser based on the abstract 
domain for non pair-sharing and freeness of [13]. It shows that linear refinement 
can be used to devise practically useful domains. We do not know of any other 
implementation of a static analysis developed through linear refinement. 

We have shown that reduction rules are necessary in order to obtain an 
efficient analysis. We have studied a sufRcient condition which entails that a 
reduction rule does not introduce any loss of precision. 

A promising widening operation would delete all the arrows whose dimension 
is too big. They are the cause of the computational cost of the analysis and are 
seldom useful in practice. Preliminary experiments have shown that a drastic 
performance improvement can be obtained. 

Our analysis is almost always as precise as a traditional goal-dependent anal- 
ysis. This justihes the research of more efficient implementations. At the same 
time, it challenges us to exploit the full power of the domain. 
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PROOFS 

We recall from [ 13 ] the following definitions. 

Definition 9 . Given V G p/(V) and {v,vi,v-2\ C V, we define (vi,V2)y = 
{3\vc G Hy I vars(c(tii)) n vars(c(v2)) = 0} and vy = {3wc G Hy \ c{v) e V LI 
W}. When the set V is obvious from the eontext, we write (vi,V2) for (vi, V2)y 
and V for vy. Given {{vl,vl), . . . ,{v^,v'^),vi, . . . ,Vm}, we write (vj,vf)... 
(vi, Vn)vi • • • Vm (the Order is irrelevant) for (ni=i....,n(vi,v?))n(ni=y.„,r„Vi). 
The linear arrow \ r is defined as 

1 -i> r = {h G Hy I for every h' G I if h h' is defined then h h' G r} 
for every 1 , r G p{Hy). 

We define the concretisation map 'jRep ■ Absy i— > p{Hy) as 
jRepiA) = Pi 1 -or 

l^r^A 



for any A G Absy. 

The following definition formalises the intuitive concept of computation. 

Definition 10 . A computation is whether an element of Absy, for any V G 
pf{V), or a term of the form op(ci, . . . , c„), where the Ci ’s are computations, op 
is the name of one of the abstract operators defined in Section 3 and its signature 
is respected. The evaluation of a computation is defined as [A] = A if A G Absy 
for some V G pf{V) and |op(ci, . . . , c„)] = op(|ci], . . . , |c„|). Moreover, if p 
is a reduction rule, we define |Gl]^ = py{A) if A G Absy for some V G p/(V) 
and [op(ci, . . . = py (op(|cip, . . . , |c„]'’)) z/ op(|cip, . . . , |c„]'’) G Absy 

for some V G p/(V). 

Proof (Proof of Proposition 1). We have to prove that every computation 
c is such that freey(|c]) C freey(|c]'’) and nshy(|c]) C nshy(|c]'’). We prove 
that all the abstract operators of Section 3 are monotonic w.r.t. This will 
entail the thesis by induction on c, since py (A) A A and it is easy to check that 
A\ < A2 entails freey(A2) C freey(Ai) and nshy(Gl2) C nshy(Gli). 

Assume V G p/(V) and A,Ai,A2 G Absy such that Ai A A2. 

We have trivially (Ai) A rename^J^f^ (^2)- 

For restrict'^^®'^ , consider I2 ^ r G restrict^ ^'^(^2). Then I2 — l'2 \ X with 
I2 ^ r G A2, (x,x) ^ I2 and X as dehned in Definition 4 . Then there exists 
l[ ^ r G Ai such that I'l C I2U {(f,u') \ v,v' G V, v v' , (v,v) G Z2}. Since 
{x,x) ^ I2, we have (x,x) ^ l[. Therefore, l[\X ^ r G restrict^^^'^(Ai), and 
l[\X Ch2'J{(v,v') \v,v' GV, vfi^v', {v,v)Gl'2}\X={l'2\X)U{{v,v') I 
v,v' G V \ x, V ^ v', (v, v) G I2 \ X}, since (x, x) ^ I2. 

For expand'^^®'^ , let I2 => r G expand]^^®'^ (A2) with I2 => r G A2. Then there 
exists h ^ r G Ai with l\ GI2G {(w,u') \ v,v’ G V, v v', (v,v) G I2} and 
h^rG expandf^^(Ai). If Z 2 [n/?i][?l/? 2 ] ^ r[n/?i][?l/? 2 ] G expand^ (A2) 
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with I 2 ^ r G A 2 , then there exists h ^ r G Ai with C ^2 U {(r’,f') \v,v’ G 
V, V ^ v', (v,v) G h}- Therefore, ^i[n/?i][?l/?2] C l2[n/li][!l/12] U {(v,i’') | 
v,v' G V, V ^ v', (v,v) G ;2}[n/?i][?l/?2] C Z2[n/?i][?l/?2] U {(w,t;') j v,v' G 
V Un, V ^ v' , (v,v) G Z2[n/?i][?l/?2]}. Since ^i[n/?i][?l/?2] ^ r[n/?i][?l/?2] G 
expandj^^®^ (yli), we have the thesis. 

For consider I 2 I ^ r G (A 2 , A), with I 2 ^ r G A 2 and I ^ r G 

A. There exists h ^ r G Ai with li C l 2 U{{v, v') \v,v' gV, v ^ v' , {v, v) G h}- 
Therefore, l\l C I 2 I U {{v,v') \ v,v' G V, v ^ v\ (v,v) G h} C I 2 I U {[v,v') \ 
v,v' G V, V ^ v', (v,v) G hlj- Since hi ^ r G (Ai, A) and the same 

argument can be used for the symmetrical case of the definition of ^ 

have the thesis. 

For consider h ■ ■ ■ In => r G A 2 A, with ri • • • r„ =i> r G A U T 

(T is the set of Definition 3), Zi =i> r' G 2 I 2 U T and rj C r, for z = 1, . . . , n. 
Then l[ ^ r[ G A\\JT with ^ C hu {(«,«') \ v,v' G V, v ^ v', {v,v) G k} 
and h' ■ => r G Ai with l[ - • - l'^ C h • • • InG) {{v, v') \v,v'gV, v ^ 

v', (v, v) G h • • • In}- Consider now h • • • In ^ r G A 2 *^^®v A with ri • • • r„ 
r G A 2 U T, h => h € AU T and rl C r,. There exists 1' ^ r G Ai LI T 
such that I' C n • • - r„ U {(u,f') \ v,v’ G V, v ^ v', (v,v) G ri ■ ■ -r„}. Given 
k G I', whether /c G n • • • r„ or fc = (u, v') with {v, v) G A ■■ ■ r„. In both cases 
there exists i, 1 < z < n, such that r- C ri C k, and we can select a set S 
of natural numbers between 1 and rz such that Ui^sh ^ r G A\ a and 

Uies^i ^h - ■ - In ^h - ■ -InU {iy,v') \ V,v' gV, V ^ v', {v, v) G h-" In}- The 
other case of *'^^®v is symmetrical. 

Given V G p/(V) and two arrows I ^ r and I' ^ r' , we write i ^ r A Z' ^ r' if 
and only if r = r' and I C Z' U {(z;, v') \ v,v' G V,v v' , (v, v) G Z'}. The relation 
^ turns out to be a well founded partial order. It is obvious that A A A' if and 
only if for each arrow a' G A! there exists an arrow a G A such that a < a' . 

Proof (Proof of Proposition 2). Given an arrow a G A, let us consider the set 
of all the arrows b G A with b A o,, which we denote by }a. If Jf < A, the least 
element of }a, namely pj [a has to be in A' . It turns out that A = {n(io) \ a G A} 
is the least subset of A according to the ^ ordering. It is easy to check that 
A = p\A). 

Now, we want to prove that jj{ep(p^(A)) = 'ynep(A). It is enough to prove 
that, given two arrows a and a', if a ^ a' then j Rep [of G jRep{a')- If a ^ o', 
then a = I ^ r, a' = I' ^ r and 7flep(Z) A 'jRep{l')- By properties of the linear 
refinement, 'yRep{a) C 'fRep{a') follows. 

Proof (Proof of Proposition 3). Given V G p/(V), the map py, applied to 
A G Absv, removes {v, v') from the left hand side of Z ^ r if and only if (v, v) G I 
and V f=- v' . Therefore it is reductive w.r.t. Moreover, 6\m{py{A)) < dim(Gl) 
and jRep{A) = jRep{py{A)). Indeed, given h G Hy, if h G (v,v) then h is 
ground and h G (v, v') for any v' G V. 
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Abstract. Partial evaluation is an automatic technique for program op- 
timization which preserves program semantics. The range of its potential 
applications is extremely large, as witnessed by successful experiences in 
several fields. This paper summarizes our findings in the development of 
partial evaluation tools for Curry, a modern multi-paradigm declarative 
language which combines features from functional, logic and concurrent 
programming. From a practical point of view, the most promising ap- 
proach appears to be a recent partial evaluation framework which trans- 
lates source programs into a maximally simplified representation. We 
support this statement by extending the underlying method in order 
to design a practical partial evaluation tool for the language Curry. The 
process is fully automatic and can be incorporated into a Curry compiler 
as a source-to-source transformation on intermediate programs. An im- 
plementation of the partial evaluator has been undertaken. Experimental 
results confirm that our partial evaluator pays off in practice. 



1 Introduction 

Curry [13, 15] is a modern multi-paradigm declarative language which integrates 
features from functional, logic and concurrent programming. The most impor- 
tant features of the language include lazy evaluation, higher-order functions, 
non-deterministic computations, concurrent evaluation of constraints with syn- 
chronization on logical variables, and a unified computation model which inte- 
grates narrowing and residuation. Furthermore, Curry is a complete program- 
ming language which has been used to implement distributed applications (e.g., 
Internet servers [14], dynamic web pages [17]) or graphical user interfaces [16]. 
Several efficient implementations of the language already exist (see, e.g., [7, 18, 
25]), although there is still room for further improvements. Existing compilers for 
pure functional languages have been successfully improved by semantics-based 
program transformation techniques. For instance, the Glasgow Haskell Compiler 
includes a number of source-to-source program transformations which are able 

* This work has been partially supported by CICYT TIC 98-0445-C03-01, by Accion 
Integrada hispano-alemana HA1997-0073, and by the DEG under grant Ha 2457/1-2. 

H. Kuchen and K. Ueda (Eds.): FLOPS 2001, LNCS 2024, pp. 326-342, 2001. 

© Springer-Verlag Berlin Heidelberg 2001 
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to optimize the quality of code in many different aspects [27]. Encouraged by 
these successful experiences, we develop an automatic program transformation 
technique to improve the efficiency of Curry functional logic programs. 

For instance, consider functions defined by higher-order combinators such as 
map, f oldr, etc. Although such functions can be simply defined in a concise way, 
some overhead is introduced at runtime which can be eliminated by program 
transformation techniques. As an example, consider the following function foo: 

foo xs = foldr (-p) 0 (map (-pl) xs) 

to add 1 to the elements of a given list xs and then compute their total sum. 
From the programmer point of view, this definition is perfectly right, but there 
exist more efficient definitions for foo, like the following one: 

foo [] =0 

foo (x : xs) = (x -P 1) -P (foo xs) 

In contrast to the original definition, it is a first-order function and, over ex- 
isting functional logic compilers, it can be executed more efficiently (since it is 
completely “deforested” [30]). Therefore, we are concerned with program trans- 
formations which, given a program, output a residual program from which the 
overhead has been removed at compile time. Partial evaluation (PE) is an auto- 
matic technique for program optimization which preserves program semantics. 
Optimization is achieved by specializing programs w.r.t. parts of their input 
(hence also called program specialization). We note that several PE techniques 
are able to perform deforestation automatically and, thus, they can be useful 
to optimize functions like the above one. Informally, a partial evaluator is a 
mapping which takes a program P and a function call C and derives a more 
efficient, specialized program Pc which gives the same answers for C (and any 
of its instances) as P does. 

PE techniques have been intensively studied in the context of a wide vari- 
ety of declarative programming paradigms, specially in both the functional and 
logic programming communities (see, e.g., [9,11,20,23] and references herein). 
Recently, a unified framework for the PE of languages which integrate features 
from functional and logic programming has been introduced in [4] . The original 
framework is defined for languages whose operational semantics is based solely 
on narrowing, although it has been extended to deal with residuation in [2]. The 
Indy partial evaluator [1] is a prototype implementation based on the above 
framework. The system is written in Prolog and accepts unconditional term 
rewriting systems as programs. The narrowing-driven approach to PE has the 
same potential for specialization as positive supercompilation [29] of functional 
programs and conjunctive partial deduction [10] of logic programs (it has been 
experimentally tested in [2,4]). 

Unfortunately, the use of Indy within a realistic functional logic language 
(e.g., Curry [15], Escher [22] or Toy [24]) becomes impractical since there are 
many facilities of these languages (e.g., higher-order functions, constraints, I/O, 
built-in’s, etc.) which are not covered neither by Indy nor by the underlying PE 
framework. For instance. Indy cannot be used to optimize the above function 
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foo due to occurrences of the built-in function + and the higher-order func- 
tions map and foldr. Furthermore, the PE framework of [4] suffers from some 
limitations, e.g., within a lazy (call-by-name) semantics, terms in head normal 
form (i.e., rooted by a constructor symbol) cannot be evaluated during the PE 
process. This can drastically reduce the optimization power of the method in 
many cases. To overcome this problem, [3] introduces a novel approach for the 
PE of functional logic languages. The new scheme considers a maximally simpli- 
fied representation into which programs written in a higher-level language (i.e., 
inductively sequential programs [5] with evaluation annotations) can be auto- 
matically translated. The restriction to not evaluate terms in head normal form 
is avoided by defining a non-standard semantics which is well-suited to perform 
computations at PE time. 

The aim of this work is to show how — in contrast to [4] and Indy — the frame- 
work of [3] can be successfully applied in practice. To this end, we first enrich 
the intermediate representation considered in [3] in order to cover all the facili- 
ties of the language Curry. The resulting representation is essentially equivalent 
to the standard intermediate language ElatCurry [18], which has been proposed 
to provide a common interface for connecting different tools working on Curry 
programs, e.g., back ends for various compilers [7]. Then, the non-standard se- 
mantics of [3] is carefully extended in order to cover the additional language 
features. This extension is far from trivial, since the underlying calculus does 
not compute bindings but represents them by “residual” case expressions. How- 
ever, there are a number of functions, like equalities, (concurrent) conjunctions, 
some arithmetic functions, etc., in which the propagation of bindings between 
their arguments is crucial to achieve a good level of specialization. Therefore, we 
are constrained to define a specific treatment for these important features. Ei- 
nally, in order to make the resulting framework practically applicable, we define 
appropriate control strategies which take into account the particularities of the 
considered language and (non-standard) semantics. The resulting method is able 
to transform realistic Curry programs in contrast to other existing partial eval- 
uators. Eor instance, the “higher-order” definition of foo can be automatically 
transformed into the more efficient version (see Sect. 5). 

The structure of this paper is as follows. Section 2 recalls the basic notions 
and techniques associated to the PE of functional logic programs. Section 3 
extends the previous approach in order to cover all the facilities provided by the 
language Curry. A description of the control issues involved in the PE process is 
presented in Sect. 4. Some experiments with the partial evaluator are described 
in Sect. 5 before we conclude in Sect. 6. 

2 The Basic Approach 

Eor the sake of completeness, in this section we briefly recall the approach pre- 
sented in [3] for the PE of functional logic programs. Informally speaking, the 
process is based on two steps: firstly, the source program is translated into a 
maximally simplified representation (Sect. 2.1); then, function calls are partially 
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evaluated using a non-standard semantics, the RLNT calculus, which is specially 
well-suited for performing computations at PE time (Sect. 2.2). To be precise, 
for each finite (possibly partial) computation of the form ei performed 

with the RLNT calculus, we generate a residual rule — a resultant — of the form: 
ei = 62 . Additionally, a post-processing of renaming is often required to recover 
the same class of programs. 

2.1 The Flat Representation 

Following [13], we consider inductively sequential rewrite systems [5] (with eval- 
uation annotations) as programs and an operational semantics which integrates 
(needed) narrowing and residuation. In order to simplify the underlying seman- 
tics, a flat representation for programs is introduced. This representation is based 
on the formulation of [19] to express pattern-matching by case expressions. As 
it will become apparent in Sect. 3, it corresponds to a subset of the FlatCurry 
syntax [18], a standard intermediate representation for Curry programs. 

TZ ::= Di . . . Dm e ::= x (variable) 

D ::= f{xi, . ■ ■ ,x„) = e \ (constructor) 

I /(ei,..., 6 n) (function call) 

p ::= c{xi, . ■ ■ ,Xn) I case eo o/ {pi -)■ ei; . . . -)■ e„} (rigid case) 

I fcase eo of {pi — )■ ei; . . . ;pn — )■ On} (flexible case) 

A program TZ consists of a sequence of function definitions D such that each 
function is defined by one rule whose left-hand side contains only variables as 
parameters. The right-hand side is an expression e composed by variables, con- 
structors, function calls, and case expressions for pattern-matching. The form of 
a case expression is:^ 

{f)case e of ei; . . .;ck{^) e*} 

where e is an expression, ci, . . . , are different constructors of the type of e, 
and 6 i, . . . , 6 ^; are expressions (possibly containing (f)case’s). The variables 
are local variables which occur only in the corresponding subexpression e,. The 
difference between case and fcase only shows up when the argument e is a free 
variable: case suspends (which corresponds to residuation) whereas fcase nonde- 
terministically binds this variable to a pattern in a branch of the case expression 
(which corresponds to narrowing). Functions defined only by fcase (resp. case) 
expressions are called flexible (resp. rigid). Thus, flexible functions act as genera- 
tors (like predicates in logic programming) and rigid functions act as consumers. 
For example, consider the rules defining the (rigid) function “ ^ 

0 ^ n = True 

(Succ m) ^ 0 = False 

(Succ m) ^ (Succ n) = m ^ n 

Using case expressions, they can be represented by the following rewrite rule: 

^ We write oT for the sequence of objects oi, . ■ ■ ,On- 

^ Although we consider in this work a first-order representation for programs, we use 
a curried notation in concrete examples (as usual in functional languages). 
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X ^ y = case x of {0 True; 

(Succ Xi) case y of {0 False; 

(Succ yi) xi ^ yi} } 

An automatic transformation from inductively sequential programs [5] to pro- 
grams using case expressions is introduced in [19]. 



2.2 The Residualizing Semantics 

The operational semantics of fiat programs becomes simpler, since definitional 
trees [5] (used to guide the needed narrowing strategy [6]) have been compiled in 
the program by means of case expressions. The LNT calculus [19] (Lazy Narrow- 
ing with definitional Trees) is an operational semantics for inductively sequential 
programs expressed in terms of case expressions, which has been proved equiva- 
lent to needed narrowing. This calculus has been also extended to cover programs 
containing evaluation annotations in [3]; namely, flexible (resp. rigid) functions 
are translated by using only fease (resp. ease) expressions. In the following, we 
refer to the LNT calculus to mean the LNT calculus of [3]. 

In [3], it was shown that, by using the standard semantics during PE, one 
would have the same problems of previous approaches. In particular, one of the 
main problems comes from the baekpropagation of variable bindings to the left- 
hand sides of residual rules (see Example 2 of [3]). Therefore, they propose a 
residualizing version of the LNT calculus which avoids this restriction. In this 
calculus, variable bindings are encoded by case expressions (and are consid- 
ered “residual” code). The inference rules of the residualizing calculus, RLNT 
(Residualizing LNT), can be seen in Eig. 1. In the following, we consider a {niany- 
sorted) signature partitioned into a set C of eonstruetors and a set T of defined 
funetions or operations. 

Let us recall the six inference rules defining the one-step relation 

(1) HNF. The HNF (Head Normal Eorm) rules are used to evaluate terms in 
head normal form. If the expression is a variable or a constructor constant, the 
square brackets are removed and the evaluation process stops. Otherwise, the 
evaluation proceeds with the arguments. 

(2) Case Function. This rule can be only applied when the argument of the case 
is operation-rooted. In this case, it allows the unfolding of the function call. 

(3) Case Select. This rule selects the appropriate branch of a case expression 
and continues with the evaluation of this branch. 

(4) Case Guess. The treatment of case expressions with variable arguments dis- 
tinguishes it from the LNT calculus. In the standard semantics, these expressions 
are evaluated by means of the following rules: 

- fease: [fease x of {pk -J- e*}] [o-(e*)l if cr = {a; ha pi}, i = l,...,k 

- case: [case x of {pk e^,}] case x of {pk ek} 



® The symbols “|” and “]” in an expression like |e] do not denote a semantic function 
but are only used to identify which part of an expression should be still evaluated. 
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HNF 



|f] t if f € V or f = c() with c/0 € C 



Case-of-Case 

|(/)case (if) case t of {pTTt^}) of {p'j f'}] 



Case Function 

lif)case g{Uf) of 

Case Select 

|(/)case c(LT) of 
Case Guess 

[if) case X of 

Function Eval 



{pk - 




{pk - 






7*}] 


[9(G)] 



|(/)case t of {pk if) case tk of {p'j f'}}] 



|(/)case <r(r) of {pk t'Jj 

if g{x^) = r 6 7?. is a rule with fresh variables 

and <T = {x„ 

|<r(f')] if Pi = c(^), C 6 C, <T = {Xn l-t tn} 



(f)case X of {pk [o-*(t*)]} 
if ai = {x Pi}, i = 1,. . . ,k 

|<r(r)] if g{x^) = r 6 7?. is a rule with fresh 
variables and a = {x„ t„} 



Fig. 1. RLNT Calculus 

However, in this case, one would inherit the limitations of previous approaches. 
Therefore, it has been modified in order not to backpropagate the bindings of 
variables. In particular, the new Case Guess rule “residualizes” the case struc- 
ture and continues with the evaluation of the different branches (by applying 
the corresponding substitution in order to propagate bindings forward in the 
computation). It imitates the instantiation of variables in the standard evalua- 
tion of a flexible case but keeps the case structure. Due to this modification, no 
distinction between flexible and rigid case expressions is needed in the RLNT 
calculus. Moreover, the resulting calculus does not compute “answers”. Rather, 
they are represented in the derived expressions by means of case expressions 
with variable arguments. Also, the calculus becomes deterministic, i.e., there is 
no don’t know nondeterminism involved in the computations. This means that 
only one derivation can be issued from a given expression (thus, there is no need 
to introduce a notion of RLNT “tree”). 

(5) Case-of-Case. An undesirable effect of the Case Guess rule is that nested case 
expressions may suspend unnecessarily. Take, for instance, the expression: 

[case (case x of { 0 True 

(Succ y) False}) of {True C x}] 

The evaluation of this expression suspends since the outer case can be only eval- 
uated if the argument is a variable (Case Guess), a function call (Case Eval) or 
a constructor-rooted term (Case Select). To avoid such premature suspensions, 
the Case-of-Case rule moves the outer case inside the branches of the inner one 
and, thus, the evaluation of some branches can now proceed (similar rules can 
be found in the Glasgow Haskell Compiler as well as in Wadler’s deforestation 
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[30]). By using the Case-of-Case rule, the above expression can be reduced to: 

[case X of {0 case True of {True — >• C x} 

(Succ y) case False of {True C x}] 

(which can be further simplified with the Case Guess and Case Select rules). Rig- 
orously speaking, this rule can be expanded into four rules (with the different 
combinations for case and fcase), but we keep the above (less formal) presen- 
tation for simplicity. Observe that the outer case expression may be duplicated 
several times, but each copy is now (possibly) scrutinizing a known value, and 
so the Case Select rule can be applied to eliminate some case constructs. 

(6) Function Eval. This rule performs the unfolding of a function call. As in 
proof procedures for logic programming, we assume that we take a program rule 
with fresh variables in each such evaluation step. 

The correctness of the PE scheme for fiat programs based on the RENT calculus 
can be found in [3]. 

3 Extending the Basic Framework 

The aim of this section is to extend the basic approach in order to cover the 
facilities of a realistic multi-paradigm language: Curry [15]. To this end, we first 
enrich the fiat representation of Sect. 2.1 with some additional features which 
constitute the most useful facilities of the language. Then, we correspondingly 
extend the rules of the RENT calculus to properly deal with these new features. 



3.1 An Intermediate Representation for Cnrry Programs 



Our extended fiat representation essentially coincides with the standard inter- 
mediate representation, FlatCurry [18], used during the compilation of Curry 
programs. It contains all the necessary information about a Curry program with 
all “syntactic sugar” compiled out and type-checking and lambda-lifting per- 
formed. In the extended representation, we allow the following expressions: 



c(ei , . . . , 6n) 

/ (ei , . . . , 6n) 

{f)case eo o/ {pi -)• ei; . . . -)• e„} 

external{e) 

partcall{f, ei, . . . , e*) 

apply{ei, 62) 

constr({xi , . . . , x„}, e) 

or(ei, 62) 

guarded{{xi , . . . , Xn}, ei, 62) 



(variable) 

(constructor) 

(function call) 

(case expression) 
(external function call) 
(partial application) 
(application) 
(constraint) 
(disjunction) 

(guarded expression) 



The right-hand side of each function definition is now an expression e com- 
posed by variables, constructors, function calls, case expressions, and additional 
features like: non user-defined (“external”) functions, higher-order features like 
partial application and an application of a functional expression to an argument. 
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constraints (like equational constraints ei =:= 62 , possibly containing existen- 
tially quantified variables) , disjunctions (to represent functions with overlapping 
left-hand sides), and guarded expressions (to represent conditional rules, i.e., 
the first expression is always a constraint and the list of variables are the local 
variables which are visible in the constraint and the right-hand side) . A detailed 
description of these features and their intended semantics can be found in [15]. 

3.2 Extending the RLNT Calcnlns 

In principle, one could extend the RLNT calculus in order to deal with all the 
facilities of FlatCurry in a simple way. The naive idea is to treat all the additional 
features of the language as constructor symbols at PE time. This means that they 
are never partially evaluated but their original definitions are returned by the PE 
process. However, in realistic Curry programs, the presence of these additional 
features is perfectly common, hence it is an unacceptable restriction just to 
resi dualize them. Our experimental tests have shown that no specialization is 
obtained in most cases if we follow this simple approach. 

On the other hand, extending the RLNT calculus of Sect. 2.2 with the stan- 
dard semantics for the additional features of ElatCurry is not a good solution 
either. The problem stems from the fact that the RLNT calculus only propagates 
bindings forward into the branches of a case expression. However, there are a 
number of functions, like equalities, (concurrent) conjunctions, some arithmetic 
functions, etc., in which the propagation of bindings between their arguments is 
crucial to achieve a good level of specialization. In order to propagate bindings"^ 
between different arguments, we permit to lift some case expressions from argu- 
ment positions to the top level while propagating the corresponding bindings to 
the remaining arguments. Eor example, the expression® 

|(x =:= 1) & (fcase x of {1 success})] 
can be transformed into 

[fcase X of {1 (x =:= 1 & success)}] 

The transformed expression can be now evaluated by the Case Guess rule, thus 
propagating the binding {x ha 1 } to the first conjunct: 

fcase X of {1 [1 =:= 1 & success]} 

We notice that this transformation cannot be applied over arbitrary expressions 
since the intended (lazy) semantics is only preserved when the given function 
is strict in the position of the case expression. Nevertheless, typical ElatCurry 
programs contain many elements where the evaluation order is fixed. Eor in- 
stance, the condition of a guard is strict, since it must be reduced to True (or 
“success”) before applying a conditional rule, the arguments of most external 
functions are also strict, because they must be reduced to ground constructor 
terms before executing the external call, etc. 

* Recall that bindings are represented by case expressions with a variable argument. 

® Following [15], “success” denotes a constraint which is always solvable. 
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Furthermore, there are a number of situations in which an expression cannot 
be evaluated until all (or some) of its arguments have some particular form. For 
example, a call of the form apply ( 61 , 62 ) can be only reduced if the first argu- 
ment ei is of the form parteall(. . In these cases, we will try to evaluate the 
arguments of the function to achieve the required form. For the sake of a simpler 
presentation, we introduce the auxiliary function try- 6 val. Given a function call 
/(^) and a set of natural numbers I which represents the set of strict arguments 
of function /, we define try- 6 val as follows: 



try. 6 val(f{ 6 n),I) = < 



lif)caS6 X of {Pk f(6i ,. . . ,6j- i,6'i^,6i+i, . . . ,e„)}] 
if 6i = (f)eas6 X of {pk -^6'/^} for some i G I 

^f j ^i—l j j • • • 7^n)l 

ii3i e {!,..., n}. [[ej] =1> e'', e' = de/^,(e''), e' 
/(^) otherwise 



Here we denote by dolsqio) the expression which results from deleting all oc- 
currences of “I” and “]” from e. We use it to test syntactic equality between 
expressions without taking into account the relative positions of “|” and “]”. 
Let us informally explain the function above. First, try.oval tries to float a case 
expression in the Gth argument (with i £ I) out of this argument. If this is 
not possible, it tries to evaluate some argument and, if this does not lead to 
a progress, the expression is just residualized. Since this definition of try.oval 
is ambiguous, we additionally require that the different cases are tried in their 
textual order and the arguments are evaluated from left to right. 



Non User-Defined Fnnctions. FlatCurry programs often contain functions 
which are not defined in Curry but implemented in another language (exter- 
nal functions, like arithmetic operators, basic input/output facilities, etc). Such 
functions are executed only if all arguments are evaluated to ground constructor 
terms.® The same restriction seems reasonable when computing the PE of an 
external function. This implies that all arguments of external functions are as- 
sumed to be strict and, thus, the call to try-eval is performed with the complete 
set of argument positions: 

{ 6 xt- 6 all(f fe^)) if ei, . . . , e„ are ground constructor 
[ea;terna/(e')] if try.eval(f(^), {1, . . . , n}) = [e'J 
external (f(^)) otherwise 

where ext-eall(e) evaluates e according to its predefined semantics. Basically, 
the partial evaluator first tries to execute the external function and, if this is not 
possible because all arguments are not ground constructor terms, then it tries 
to evaluate its arguments. Furthermore, we need to add the rule: 

\external((f)ease x of {pk e^,})] => |(/)case x of {pk external(ek)}] 

to move a case expression obtained by try^eval outside the external call (in order 
to allow further evaluation of the branches) . 



® There are few exceptions to this general rule but typical external functions (like 
arithmetic operators) fulfill this condition. We assume it for the sake of simplicity. 
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The only exception to the above rule are I/O actions, for which Curry follows 
the monadic approach to I/O. These functions act on the current “state of the 
outside world” . They are residualized since this state is not known at PE time. 

Constraints. The treatment for constraints heavily depends on the associated 
constraint solver. In the following, we only consider equational constraints. An 
elementary constraint is an equation ei =:= 62 between two expressions which 
is solvable if both sides are reducible to unifiable constructor terms. This notion 
of equality, the so-called strict equality, is incorporated in our calculus by 

{ caseo- (success) if <7 = mgu{e\, 62 ) and 61,62 

are constructor terms 
try-eval{e\ =:= 62 , { 1 , 2 }) otherwise 

Note that we call to try.eval with the set of positions {1,2} since function 
is strict in its two arguments. Here, we use 6056^ (success) as a shorthand for 
denoting the encoding of a by nested (flexible) case expressions with success at 
the final branch. For example, the expression |C x 2 =:= C 1 y], whose mgu is 
{x H- >• 1 , y HA 2 } is evaluated to: fcase x of {1 fcase y of {2 success}}. 
This simple treatment of constraints is not sufficient in practical programs since 
they are often used in concurrent conjunctions, written as ci & . . . & c„ (“&” 
is a built-in operator which evaluates its arguments concurrently). In this case, 
constraints may instantiate variables and the corresponding bindings should be 
propagated to the remaining conjuncts. The problematic point is that we cannot 
move arbitrary case expressions to the top level, but only flexible case expressions 
(otherwise, we could change the floundering behavior of the program). Consider, 
for instance, the following simple functions: 

f X = case X of {1 success} 
g X = fcase X of {1 success} 

where f is rigid and g is flexible. Given the expression [f x & g x], if we allow to 
float out arbitrary case expressions, we could perform the following evaluation: 

|f X & g x] [case x of {1 success} & g x] 

[case X of {1 success & g x}] 

=> case X of {1 — >• [success & g 1]} 

which ends up in case x of {1 success}. Note that this residual expression 
suspends if variable x is not instantiated, whereas the original expression could 
be reduced by evaluating first function g and then function f. Therefore, we 
handle concurrent conjunctions as follows: 

[Ci & . . . & 6 „] 

' success if Ci = success for all i € { 1 , . . . , n} 

|/caS 6 X of {Pk ^ {ci k .. . & 6 j_i fc 6 } fc 6 j+i & ... & 6 „)}] 

I if Cj = fcase x of {pk e}} for some i € { 1 , . . . ,n} 

|ci & . . . & 6 j_i & c' & 6 j+i & ... & 6 „] 

ii3i e {!,..., n}. [cj] c'', c' = delsq{c”),Ci c' 

_ 6 i & ... & 6 „ otherwise 
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Note that, in contrast to external functions, only flexible case expressions are 
moved to the top level. Equational constraints can also contain local existen- 
tially quantified variables. In this case they take the form constr(vars,c), where 
vars are the existentially quantified variables in the constraint c. We treat these 
constraints as follows: 



lconstr(vars, c)] 



J success if c = success 

I try -eval {con str {vars, c), { 2 }) otherwise 



Note that the above rule moves all bindings to the top level, even those for 
the local variables in vars. In practice, case expressions denoting bindings for 
the variables in vars are removed since they are local, but we keep the above 
formulation for simplicity. 



Guarded Expressions. In Curry, functions can be defined by conditional rules 
of the form 



/ ei . . . e„ I c = e 

where c is a constraint (rules with multiple guards are also allowed but consid- 
ered as syntactic sugar for denoting a sequence of rules). Conditional rules are 
represented in FlatCurry by the guarded construct. At PE time, we are inter- 
ested in inspecting not only the guard but also the right-hand side of the guard. 
However, only bindings produced from the evaluation of the guard can be floated 
out (since this is the unique strict argument): 

r 7 7/ \Ti f fel if gc = success 

lguarded{vars,gc,e)\ ^ [t,y_,^^i^^^M{vars,gc,e),{2}) otherwise 

As in the case of constraints, the application of try.eval can unnecessarily move 
some bindings (i.e., those for the variables in vars) outside the guarded ex- 
pression. A precise treatment can be easily defined, but we preserve the above 
presentation for the sake of readability. 

Higher-Order Functions. The higher-order features of functional program- 
ming are implemented in Curry by providing a (first-order) definition of the 
application function {apply). Since Curry excludes higher-order unification, the 
operational semantics of Curry covers the usual higher-order features of func- 
tional languages by adding the following axiom [ 15 ]: 

lapply{f{ei , . . . ,e™),e)] /(ei, . . . ,e™,e) 

if / has arity n > m. Thus, an application is evaluated by simply adding the ar- 
gument to a partial call. In FlatCurry, we distinguish partial applications from 
total functions; namely, partial applications are represented by means of the 
partcall symbol. We treat higher-order features as follows: 

{ [/(c*,e2)] if ei = partcall {f,'^), k + l = ar{f) 

partcall{f,c^,e2) if ei = partcall{f,c^), k + 1 < ar{f) 

try-eval {apply {61,62), { 1 }) otherwise 

where ar{f) denotes the arity of the function /. Roughly speaking, we allow a 
partial function to become a total function by adding the missing argument, 
if possible. If the function does not have the right number of arguments after 
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adding the new argument, we maintain it as a partial function. In the remaining 
cases, we evaluate the apply arguments in hopes of achieving a partial call after 
evaluation. Note that try.eval is called with the set {1} in order to avoid the 
propagation of bindings from the evaluation of non-strict arguments (i.e., from 
the second argument of apply). 

Overlapping Left-Hand Sides. Overlapping left-hand sides in Curry pro- 
grams produce a disjunction where the different alternatives have to be consid- 
ered. Similarly, we treat or expressions in FlatCurry as follows: 

[or(ei,e 2 )l =1> or([ei], [[e 2 l) 

4 The Partial Evaluator in Practice 

In this section, we describe the structure of a simple on-line partial evaluator in 
the style of [11] which follows the ideas presented so far. Essentially, the partial 
evaluator proceeds as follows: 

Unfolding phase. Firstly, given a program and a set of function calls, we 
compute a finite (possibly incomplete) RENT derivation for each call of the set 
according to an unfolding rule U. Roughly speaking, the unfolding rule deter- 
mines how to stop RENT derivations in order to avoid infinite computations. 
Formally, given a program TZ and a set of function calls T = {ti, . . . ,t„}, U is 
a (total) function such that, whenever L({T,TZ) = S, then 5 = {si, . . . ,s„} and 
there exist finite RENT derivations of the form s, in TZ, with i = 1, . . . ,n. 

Abstraction phase. Since some of the derived expressions S = {si, . . . ,s„} 
may contain function calls which are not covered by the already (partially) eval- 
uated calls T, this process is iteratively repeated for any term of S which is not 
elosed w.r.t. the set T. Informally, a term s is closed w.r.t. a set of terms T (or, 
simply, T-closed) if the maximal operation-rooted subterms of s are instances 
of some terms in T and the terms in the matching substitution are recursively 
T-closed (see [4] for a precise definition) . In order to avoid repeating this process 
infinitely, an abstraetion operator is commonly used. In particular, we consider a 
mapping abstract which takes two sets of terms T and S (which represent the set 
of terms already evaluated and the set of terms to be added to this set, respec- 
tively) and returns a safe approximation abstract{T, S) of TU5. Here, by “safe” 
we mean that each term in TU 5 is closed w.r.t. the result of abstract{T, S) (i.e., 
no function call is lost during the abstraction process). 

Following the structure of many on-line partial evaluators (see, e.g., [11]), we 
sketch a PE algorithm which is parametric w.r.t. an unfolding rule U and an 
abstraction operator abstract: 

Input: a program TZ and a set of terms T / Output: a set of terms S 
Initialization: i := 0; Tq := T 

Repeat S := Ll(Ti,TZ); T,_|_i := abstract(Ti, S); i := i 1 
Until T, = T,_i (modulo renaming) 

Return S := Ti 
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The above PE algorithm involves two control issues: the so-called local control, 
which concerns the definition of an unfolding rule U to compute finite partial 
evaluations, and the global control, which consists of defining a safe abstraction 
operator abstract to ensure the termination of the iterative process. 

Local Control. In the local control, the main novelty w.r.t. previous partial 
evaluators for functional logic programs is the use of a non-standard semantics, 
the RNLT calculus, to perform computations at PE time. Since RENT compu- 
tations do not produce bindings, the restriction to not evaluate terms in head 
normal form of previous partial evaluators is avoided. 

In order to ensure the finiteness of RENT derivations, there exist a number 
of well-known techniques in the literature, e.g., depth-bounds, loop-checks, well- 
founded (or well-quasi) orderings (see, e.g., [8, 21, 28]). Eor instance, an unfolding 
rule based on the use of the homeomorphic embedding ordering was used in the 
Indy partial evaluator. Informally, expression ei embeds expression C 2 if 62 can 
be obtained from ei by deleting some operators. Eor example, Succ ( Succ {(u + 
w) X ( u+ (Succ u)))) embeds Succ (u x (u + v)). However, in the presence of an 
infinite signature (e.g., natural numbers in Curry), this unfolding rule can lead 
to non-terminating computations. Eor example, consider the following Curry 
program which generates a list of natural numbers within two given limits: 

enum a b = if a > b then [] else (a : enum (a -|- 1) b) 

During its specialization w.r.t. the call enum 1 n, the following calls are produced: 
enum 1 n, enum 2 n, enum 3 n, . . . , and no call embeds some previous call. 

Therefore, in our partial evaluator we have chosen a safe (and “cheap”) un- 
folding rule: only the unfolding of one function call is allowed (the positive super- 
compiler of [20] employs a similar strategy) . The main advantage of this approach 
is that expressions can be “folded back” (i.e., can be proved closed) w.r.t. any 
partially evaluated call. In practice, this generates optimal recursive functions in 
many cases. As a counterpart, many (unnecessary) intermediate functions may 
appear in the residual program. This does not mean that we incur in a “code 
explosion” problem since this kind of redundant rules can be easily removed by 
a post-unfolding phase (similarly to [20]). Our experiments with the one-step 
unfolding rule and the post-unfolding phase indicate that this leads to optimal 
(and concise) residual functions in many cases. 

Global Control. As for global control, an abstraction operator usually relies 
on a concrete ordering over terms in order to keep the sequence of partially eval- 
uated terms finite. As discussed above, a well-quasi ordering like the homeomor- 
phic embedding ordering cannot be used since we consider an infinite signature. 
Therefore, we implement an abstraction operator which uses a well-founded or- 
der to ensure termination and generalizes those calls which do not satisfy this 
ordering by using the msg (most specific generalization) . Abstraction operators 
based on this relation are defined in, e.g., [26]. 

The main novelty of our abstraction operator w.r.t. previous operators is 
that it is guided by the RENT calculus. The key idea is to take into account the 
position of the square brackets of the calculus in expressions; namely, subterms 
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within square brackets should be added to the set of partially evaluated terms (if 
possible, otherwise generalized) since further evaluation is still required, while 
subterms which are not within square brackets should be definitively residualized 
(i.e., ignored by the abstraction operator, except for operation-rooted terms). 
The combination of this strategy with the above unfolding rule gives rise to 
efficient residual programs in many cases, while still guaranteeing termination. 

5 Experimental Results 

This section describes some experiments with an implementation of a partial 
evaluator for Curry programs which follows the guidelines presented in previous 
sections. Our PE tool is implemented in Curry itself and it is publicly available 
at http://www.dsic.upv.es/users/elp/soft.html. The implemented partial 
evaluator first translates the subject program into a FlatCurry program. To do 
this, we use the module Flat for meta-programming in Curry (included in the 
current distribution of PAKCS [18]). This module contains datatype definitions 
to treat FlatCurry programs as data objects (using a kind of ground represen- 
tation). In particular, the I/O action readFlatCurry reads a Curry program, 
translates it to the intermediate language FlatCurry, and finally returns a data 
structure representing the input program. 

The effectiveness of the narrowing-driven approach to PE is out of question 
(see, e.g., [2-4] for typical PE benchmarks). Unfortunately, these ad-hoc pro- 
grams do not happen very frequently in real Curry applications. This motivated 
us to benchmark more realistic examples where the most important features 
of Curry programs appear. One of the most useful features of functional lan- 
guages are higher-order functions since they improve code reuse and modularity 
in programming. Thus, such features are often used in practical Curry programs 
(much more than in Prolog programs, which are based on first-order logic and 
offer only weak features for higher-order programming). Furthermore, almost 
every practical program uses built-in arithmetic functions which are available 
in Curry as external functions (but, for instance, not in purely narrowing-based 
functional logic languages) . These practical features were not treated in previous 
approaches to PE of functional logic languages. 

The following functions map (for applying a function to each element of a 
list) and foldr (for accumulating all list elements) are often used in functional 
(logic) programs: 

map _ [] = [] foldr - z [] = z 

map f (x : xs) = f x : map f xs foldr f z (h : t) = f h (foldr f z t) 

For instance, the expression foldr (-I-) 0 [1,2,3] is the sum of all elements 

of the list [1,2,3]. Due to the special handling of higher-order features {apply 

and partcall) and built-in functions {external) , our partial evaluator is able to 
reduce occurrences of this expression to 6. However, instead of such constant 
expressions, realistic programs contain calls to higher-order functions which are 
partially instantiated. For instance, the expression foldr (-I-) 0 xs is specialized 
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Benchmark 


original 


specialized 


speedup 


time 


heap 


time 


heap 


foldr (+) 0 xs 


210 


2219168 


60 


619180 


3.5 


foldr (+) 0 (map (+1) xs) 


400 


4059180 


100 


859180 


4.0 


foldr (+) 0 (map square xs) 


480 


4970716 


170 


1770704 


2.8 


foldr (++) [] xs (concat) 


290 


2560228 


110 


560228 


2.6 


filter (>100) (map (*3) xs) 


750 


6639908 


430 


3120172 


1.7 


map (iterate (+1) 2) xs 


1730 


17120280 


600 


6720228 


2.9 



Table 1. Benchmark results 



by our partial evaluator to f xs where f is a first-order function defined by: 

f [] =0 

f (x : xs) = X -b f xs 

Calls to this residual function run 3.5 times faster (in the Curry^-Prolog com- 
piler [7] of PAKCS [18]) than calls to the original definitions; also, memory usage 
has been reduced significatively (see Table 1, first row). Similarly, the expres- 
sion foldr (-b) 0 (map (-bl) xs) has been successfully specialized to the efficient 
version of Sect. 1. Note that our partial evaluator neither requires function defi- 
nitions in a specific format (like “foldr/build” in short cut deforestation [12]) nor 
it is restricted to “higher-order macros” (as in [30]), but can handle arbitrary 
higher-order functions. For instance, the higher-order function 

iterate f n = if n == 0 then f else iterate (f .f) (n — 1) 

which modifies its higher-order argument in each recursive call (f .f denotes func- 
tion composition) can be successfully handled by our partial evaluator. Table 1 
shows the results of specializing some calls to higher-order and built-in functions 
with our partial evaluator. For each benchmark, we show the execution time and 
heap usage for the original and specialized calls and the speedups achieved. The 
input list xs contains 20,000 elements in each call. Times are expressed in mil- 
liseconds and measured on a 700 MHz Linux-PC (Pentium III, 256 KB cache). 
The programs were executed with the Curry ^-Prolog compiler [7] of PAKCS. 

Another important feature of Curry is the use of (concurrent) constraints. 
Consider, for instance, the following function arith: 

digit 0 = success 

digit 9 = success 

arith x y = x -b x =:= y & x * x =:= y & digit x 

Calls to “arith” might be completely evaluated at PE time. Actually, our partial 
evaluator returns the residual function arith' for the call arith x y : 

arith' 0 0 = success 
arith' 2 4 = success 

In this section, we have shown the specialization of calls to some small functions. 
However, this does not mean that only the specialization of small programs is 
feasible in our PE tool. Actually, in the specialization of larger programs the 
programmer would include some annotations indicating the function calls to be 
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specialized (which usually only involve calls to small functions). In this case, 
the same program would be returned by the system except for the annotated 
calls, which are replaced by new calls to the specialized functions, together with 
the definitions of such specialized functions. The PE tool is not fully integrated 
into PAKCS yet and, thus, transformed programs cannot be directly executed 
in Curry (since they are in FlatCurry format). Our aim is to incorporate the 
partial evaluator in PAKCS as a source-to-source transformation on FlatCurry 
programs. The process would be automatic and transparent to the user. 

6 Conclusions 

This paper describes a successful experience in the development of a program 
transformation technique for a realistic multi-paradigm declarative language. 
Our method builds on the theoretical basis of [3] for the PE of functional logic 
languages. We have shown how this framework can be successfully applied in 
practice by extending the underlying method in order to cover the facilities of 
the language Curry. A partial evaluator has been implemented which is able to 
generate efficient (and reasonably small) specialized programs. 

Future work in partial evaluation of multi-paradigm functional logic lan- 
guages should still address several issues. For a more effective deployment, off- 
line partial evaluators perform a binding-time analysis which annotates each 
function call in the source program as either reducible or subject to residual- 
ize. Although our PE scheme is essentially on-line, we think that it could be 
also improved with the information gathered by a pre-processing consisting of 
a binding-time analysis. In particular, this will allow us to use the standard se- 
mantics of the language over those expressions which can be fully evaluated in 
a finite number of steps, thus improving the effectiveness of the PE process. 
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Abstract. We present a simple way to program typed abstract syntax in 
a language following a Hindley-Milner typing discipline, such as Haskell 
and ML, and we apply it to automate two proofs about normalization 
functions as embodied in type-directed partial evaluation for the simply 
typed lambda calculus: normalization functions (1) preserve types and 
(2) yield long beta-eta normal forms. 

Keywords. Type-directed partial evaluation, normalization functions, 
simply typed lambda-calculus, higher-order abstract syntax, Haskell. 



1 Introduction 

Programs (implemented in a meta language) that manipulate programs (imple- 
mented in an object language) need a representation of the manipulated pro- 
grams. Examples of such programs include interpreters, compilers, partial eval- 
uators, and logical frameworks. 

When the meta language is a functional language with a Hindley-Milner 
type system, such as Haskell [2] or ML [7], a data type is usually chosen to 
represent object programs. In functional languages, data types are instrumental 
in representing sum types and inductive types, both of which are needed to 
represent even the simplest programs such as arithmetic expressions. 

However, the object-language types of object-language terms represented by 
data types cannot be inferred from the representation if the meta language does 
not provide dependent types. Hence, regardless of any typing discipline in the ob- 
ject language, when the meta language follows a Hindley-Milner type discipline, 
it cannot prevent the construction of object-language terms that are untyped, 
and correspondingly, it cannot report the types of object-language terms that 
are well-typed. This typeless situation is familiar to anyone who has represented 
A-terms using a data type in an Haskell-like language. 
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In this article we consider a simple way of representing monomorphically 
typed A-terms in an Haskell-like language. We describe a typeful representation 
of terms that prevents one from constructing untyped object-language terms in 
the meta language and that makes the type system of the meta language report 
the types of well-typed object-language terms. 

We apply this typeful representation to type-directed partial evaluation [1, 
3], using Haskell [9]. In Haskell, the object language of type-directed partial 
evaluation is a subset of the meta language, namely the monomorphically typed 
A-calculus. Type-directed partial evaluation is an implementation of normaliza- 
tion functions. As such, it maps a meta-language value that is simply typed into 
a (textual) representation of its long beta-eta normal form. 

All previous implementations of type-directed partial evaluation in Haskell- 
like languages have the type t Term, for some t and where Term denotes 
the typeless representation of object programs. This type does not express that 
the output of type-directed partial evaluation is a representation of an object 
of the same type as the input. In contrast, our implementation has the more 
expressive type t Exp(t), where Exp denotes our typeful representation of 
object programs. This type proves that type-directed partial evaluation preserves 
types. Furthermore, using the same technique, we also prove that the output of 
type-directed partial evaluation is indeed in long beta-eta normal form. 

The rest of this article is organized as follows. In Section 2 we review a 
traditional, typeless data-type representation of A-terms in Haskell. In Section 3, 
we review higher-order abstract syntax, which is a stepping stone towards our 
typeful representation. Section 4 presents our main result, namely an extension of 
higher-order abstract syntax that only allows well-typed object-language terms 
to be constructed. In Section 5, we review type-directed partial evaluation, which 
is our chosen domain of application. Section 6 presents our first application, 
namely an implementation of type-directed partial evaluation preserving types. 
Section 7 presents our second application, namely another implementation of 
type-directed partial evaluation demonstrating that it produces long beta-eta 
normal forms. Section 8 concludes. 



2 Typeless first-order abstract syntax 

We consider the simply typed A-calculus with integer constants, variables, ap- 
plications, and function abstractions: 

(Types) t ::= a \ int \ ti ^ t 2 
(Terms) e ::= i \ x \ egei \ Ax.e 

Other base types (booleans, reals, etc.) and other type constructors (products, 
sums, lists, etc.) are easy to add. So our object language is the A-calculus. 

Our meta language is Haskell. We use the following data type to represents 
A-terms. Its constructors are: integers (iNT), variables (VAR), applications (APP), 
and functional abstractions (LAM). 
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data Term = INT Int 

I VAR String 
I APP Term Term 
I LAM String Term 

Object-language terms are constructed in Haskell using the translation below. 
Note that the type of |"e]o is Term regardless of the type of e in the A-calculus. 

[ilo = INT i 
[xlo = VAR "x" 
reoCi]o = APP |"eo]o \^l^o 
[Ax.ejo = LAM "x" \e]o 

The constructors of the data type are typed in Haskell: The term INT 9 is valid 
whereas INT "a" is not. However, Haskell knows nothing of the A-terms we wish 
to represent. In other words, the translation [-]o is not surjective: Some well- 
typed encodings of object-language terms do not correspond to any legal object- 
language term. For example, the term APP (INT 1) (LAM "x" (VAR "x"))has 
type Term in Haskell, even though it represents the term l(Aa;.a;) which has no 
type in the A-calculus. 

The fact that we can represent untyped A-terms is not a shortcoming of the 
meta language. One might want to represent programs in an untyped object 
language like Scheme [6] or even structures for which no notion of type exists. 



3 Typeless higher-order abstract syntax 

To the data type Term we add an interface using higher-order abstract syntax [8]. 
In higher-order abstract syntax, object-language variables and bindings are rep- 
resented by meta-language variables and bindings. The interface to the data type 
Term is shown in Figure 1. 

The interface consists of syntax constructors for integers, applications, and 
abstractions. There is no constructor for variables. Instead, fresh variable names 
are generated and passed to the higher-order representation of abstractions. A A- 
expression is represented by a function accepting the next available fresh- variable 
name, using de Bruijn levels. 

Object-language terms are constructed in the meta language using the fol- 
lowing translation. Note again that the type of \e~\i is Term regardless of the 
type of e in the A-calculus. 



[t] 1 = int 
\x'\i=x 
[eoeili = app 
[Ax.e] 1 = lam 



i 



[eoli rei]i 
(\a; -> [e]i) 
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module TypelessExpCint, app, lam, Exp) where 

data Term = INT Int I VAR String I APP Term Term I LAM String Term 

type Exp = Int -> Term 

int i j = INT i 

app eO el j = APP (eO j) (el j) 

lam f j = LAM V (f (\_ -> VAR v) (j + 1)) 

where v = "x" ++ show j 

Fig. 1. Typeless higher-order abstract syntax in Haskell 



This translation is also not surjective in the sense outlined in Section 2. Indeed, 
the types of the three higher-order constructors in Haskell still allow untypable 
A-terms to be constructed. These three constructors are typed as follows. 

int :: Int ^ Exp 

app :: Exp ^ (Exp ^ Exp) 

lam :: (Exp — ^ Exp) Exp 

Therefore, the term app (int 1) (Icun (\x -> x) ) still has a type in Haskell, 
namely Exp. 

4 Typeful higher-order abstract syntax 

Let us restrict the three higher-order constructors above to only yield well-typed 
terms. To this end, we make the following observations about constructing well- 
typed terms. 

— The constructor int produces a term of object-language type Int. 

— The first argument to app is a term of object-language type a ^ (3, the 
second argument is a term of object-language type a, and app produces a 
term of object-language type (3. 

— The argument to 1 ami must be a function mapping a term of object-language 
type a into a term of object-language type 13, and laun produces a term of 
object-language type a ^ (3. 

These observations suggest that the (polymorphic) types of the three con- 
structors actually could reflect the object-language types. We thus parameterize 
the type Exp with the object-language type and we restrict the types of the con- 
structors according to these observations. In Haskell we implement the new type 
constructor as a data type, not just as an alias for Int ^ Term as in Figure 1. In 
this way the internal representation is hidden. The result is shown in Figure 2. 
The three constructors are typed as follows. 
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module TypefulExp (int, app, lam, Exp) where 

data Term = INT Int I VAR String I APP Term Term I LAM String Term 
data Exp t = EXP (Int -> Term) 



int 


: : Int -> 


Exp 


Int 










app 


: : Exp (a 


-> 


b) -> 


Exp 


a -> 


Exp b 




lam 


: : (Exp a 


-> 


Exp b) 


-> 


LXp 


(a -> b) 




int 


i 




= 


EXP 


(\x 


-> INT 


i) 


app 


(EXP eO) 


(EXP 


el) = 


EXP 


(\x 


-> APP 


(eO x) (el x)) 


lam 


f 




= 


EXP 


(\x 


-> let 


V = "x" ++ show x 



EXP b = f (EXP (\_ -> VAR v)) 
in LAM V (b (x + 1))) 

Fig. 2. Typeful higher-order abstract syntax in Haskell 



int :: Int ^ Exp(lnt) 

app :: Exp(a ^ (3) (Exp(a) Exp(/3)) 
lam :: (Exp(a) — > Exp(/?)) — > Exp(a ^ (3) 

The translation from object-language terms to meta-language terms is the same 
as the one for the typeless higher-order abstract syntax. However, unlike for 
the typeless version, if e is an (object-language) term of type t then the (meta- 
language) type of |"e]i is Exp(t). 

As an example, consider the A-term A/. /(I) of type (Int a) ^ a. It 
is encoded in Haskell by [A/./(l)]i = lam (\f -> app f (int 1)) of type 
Exp((lnt — > a) ^ a). Now consider the A-term l(Aa;.a;) which is not well-typed 
in the A-calculus. It is encoded by [I(Aa;.a;)]i = app 1 (lam (\x -> x)) which 
is rejected by Haskell. 

In the remaining sections, we apply typeful abstract syntax to type-directed 
partial evaluation. 



5 Type-directed partial evaluation 

The goal of partial evaluation [5] is to specialize a program p of type t\ ^ t 2 ^ ts 
to a fixed first argument v of type t\ . The result is a residual program py that 
satisfies Pv{w) = p{v){w) for all w of type t 2 , if both expressions terminate. The 
motivation for partial evaluation is that running Pv(w) is more efficient than 
running p(v)(w). 

In type-directed partial evaluation [1,3,9,10], specialization is achieved by 
normalization. For simply typed A-terms, the partial application p(v) is resid- 
ualized into (the text of) a program py in long beta-eta normal form. That is. 
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module TypelessTdpe where 




import TypelessExp — from Figure 1 




data Reify_Ref lect (a) = 

RR { reify : : a -> Exp, 

reflect : : Exp -> a }■ 




rra = — atomic types 

RR { reify = \x -> x, 

reflect = \x -> x I 




rrf (tl, t2) = — function types 

RR { reify = \v -> lam (\x -> reify t2 (v 

reflect = \e -> \x -> reflect t2 (app e 


(reflect tl x) ) ) , 
(reify tl x)) }■ 


normalize t v = reify t v 




Fig. 3. A typeless implementation of type-directed partial evaluation 



the residual program contains no beta-redexes and it is fully eta-expanded with 
respect to its type. 

5.1 Type-directed partial evaluation in Haskell 

Figure 3 displays a typeless implementation of type-directed partial evaluation 
for the simply typed A-calculus in Haskell. To normalize a polymorphic value 
V of type t, one applies the main function normalize to the value, v, and a 
representation of the type, |t|, defined as follows. 

|of| = rra 

\ti t 2 \ = rrf (|ti|, |t 2 |) 

To analyze the type of the representations of types, we first define the instance 
of a type as follows. 

[a]o = Exp 

[t\ t2]o = [^l]o — *■ [^2]o 

Then, for any type t, the type of |t| is Reify_Reflect([t]o). Haskell infers the 
following type for the main function. 

normalize :: Reify_Reflect(a) — > a — > Exp 

This type shows that normalize maps a a-typed input value into an Exp- 
typed output value, i.e., a term. This type, however, does not show that the 
input (meta-language) value and the output (object-language) term have the 
same type. In Section 6, we show that type-directed partial evaluation is type- 
preserving, and in Section 7, we show that the output term is in normal form. 
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5.2 Example: Church numerals, typelessly 

As an example, we apply type-directed partial evaluation to specialize the addi- 
tion of two Church numerals with respect to one argument. The Church numeral 
zero, the successor function, and addition are defined as follows. 

zero : : (a -> a) -> a -> a 
zero = \s -> \z -> z 

sue n = \s -> \z -> s (n s z) 

add m n = \s -> \z -> m s (n s z) 

Specializing add with respect to 0: We specialize the addition function 

with respect to the Church numeral 0 by normalizing the partial application 
add zero. This expression has the following type. 

tadd = {{a ^ a) ^ (3 ^ a) ^ {a ^ a) ^ (3 ^ a 

This type is represented in Haskell as follows. 

|tadd| = rrf (rrf (rrf (rra, rra) , rrfCrra, rra) ) , 
rrf(rrf(rra, rra), rrfCrra, rra))) 

Thus, evaluating the Haskell expression 

normalize |tadd| (add zero) 37 

(taking 37, for example, as the first de Bruijn level) yields a representation of 
the following residual term. 

AcC37 . Ax38 . Ax39 .CC 37 (Ax4o .X 38 CC4o)a;39 

For readability, let us rename this residual term: 

\n.\s.\z.n{\n' .s n')z 

This term is the (ry-expanded) identity function over Church numerals, reflecting 
that 0 is neutral for addition. 

Haskell infers the following type of the expression normalize |tadd|- 

{{{t' t') ^ C — > t') {t' — > t') — > t' ^ t') t' , where t' = Int — > Term 

This type does not express any relationship between the type of the input term 
and the type of the residual term. 

Specializing add with respect to 5: We specialize the addition function 
with respect to the Church numeral 5 by normalizing the partial application 
add five, where five is defined as follows. 

five = sue (sue (sue (sue (sue zero))) 
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The expression add five also has the type tadd- Thus, evaluating the Haskell 
expression 

normalize |tadd| (add five) 57 

(taking 57 this time as the first de Bruijn level) yields a representation of the 
following residual term. 

Ax57 . Ax 58 . Aa;59 .X5S (X58 (xsg (X58 (xs8 (X 57 ( Axeo -X58 Xeo ) X 59 ) ) ) ) ) 

For readability, let us rename this residual term: 

An.As.Az.s(s(s(s(s(n(An'.s n')z))))) 

In this term, the successor function is applied five times, reflecting that the 
addition function has been specialized with respect to five. 

6 Application 1: Type-directed partial evaluation 
preserves types 

In this section, we use the type inferencer of Haskell as a theorem prover to show 
that type-directed partial evaluation preserves types. To this end, we implement 
type-directed partial evaluation using typed abstract syntax. 

6.1 Typeful type-directed partial evaluation (first variant) 

We want the type of normalize to be Reify_Reflect(a) ^ a ^ Exp(a). As a first 
step to achieve this more expressive type, we shift to the typeful representation 
of terms from Figure 2. The parameterized type constructor Exp(a) replaces the 
type Exp. Thus, we change the data type Reify_Reflect(a) from Figure 3 to the 
following. 

data Reify_Ref lect a = 

RR { reify : : a -> Exp a, 
reflect : : Exp a -> a } 

This change, however, makes the standard definition of rra untypable: The iden- 
tity function does not have type a — > Exp(o;) (or Exp(a) ^ a for that matter). 
We solve this problem by introducing two identity functions in the module of 
typed terms. 



coerce :: Exp(a) — > Exp(Exp(o;)) 
uncoerce :: Exp(Exp(a)) — > Exp(a) 

At first it might seem that a function of type Exp(o!) — > Exp(Exp(a)) cannot be 
the identity. However, internally Exp(t) is an alias for Int — > Term, thus discarding 
t, so in effect we are looking at two identity functions of type (Int — > Term) — > 
(Int — > Term). Figure 4 shows the required changes to the typeful representation 
of Figure 2. 
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module TypefulExpCoerce (int, app, lam, coerce, uncoerce, Exp) where 


[. . .] 




coerce 


: : Exp a -> Exp (Exp a) 


uncoerce 


: : Exp (Exp a) -> Exp a 


coerce 


(EXP f) = EXP f 


uncoerce 


(EXP f) = EXP f 


Fig. 4. Typeful higher-order abstract syntax with coercions for atomic types 



module TypefulTdpe where 




import TypefulExpCoerce — from Figure 4 




data Reify_Ref lect (a) = 

RR { reify : : a -> Exp a, 

reflect : : Exp a -> a } 




rra = — atomic types 

RR { reify = \x -> coerce x, 

reflect = \x -> uncoerce x I 




rrf (tl, t2) = — function types 

RR { reify = \v -> lam (\x -> reify t2 (v 

reflect = \e -> \x -> reflect t2 (app e 


(reflect tl x) ) ) , 
(reify tl x)) }■ 


normalize t v = reify t v 




Fig. 5. A typeful implementation of type-directed partial evaluation 



We can now define rra using coerce and uncoerce. The complete imple- 
mentation is shown in Figure 5. Types are represented as in Section 5, but the 
types of the represented types differ. We define the instance as follows. 

[a]i = Exp(a) 

[to ^ ti]i = [fo]l ^ [ti]i 

Then the type of |t| is Reify_Reflect([t]i). Haskell infers the following type for the 
main function. 



normalize :: Reify_Reflect(ct) ^ a ^ Exp(ct) 

This type proves that type-directed partial evaluation preserves types. 

N.B. The typeless implementation in Figure 3 and the typeful implementation 
in Figure 5 are as efficient. Indeed, they differ only in the two occurrences of 
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coerce and uncoerce in rra in Figure 5, which are defined as the identity 
function. 

6.2 Typeful type-directed partial evaluation (second variant) 

The two auxiliary functions coerce and uncoerce are only necessary to obtain 
an automatic proof of the type-preservation property of type-directed partial 
evaluation: They are artefacts of the typeful encoding. But could one do without 
them? In this section, we present an alternative proof of the typing of type- 
directed partial evaluation without using these coercions. Instead, we show that 
when type-directed partial evaluation is applied to a correct representation of 
the type of the input value, the residual term has the same type as the input 
value. 

To this end, we implement rra as a pair of identity functions, as in Figure 3, 
and we modify the data type Reify_Reflect by weakening the connection between 
the domains and the codomains of the reify / reflect pairs. 

module TypefulTdpe where 

import TypefulExp — from Figure 2 

data Reify_Ref lect a b = 

RR { reify : : a -> Exp b, 
reflect : : Exp b -> a } 



[. . .] 

These changes make all of rra, rrf , and normalize well- typed in Haskell. Their 
types read as follows. 



rra :: Reify_Reflect(Exp(o;))(a) 

rrf :: (Reify_Reflect(a)( 7 ), Reify_Reflect(/3)(i5)) ^ 

Reify_Reflect(a — > (3){'y ^ i5) 
normalize :: Reify_Reflect(a)(/3) ^ a Exp(/3) 

The type of normalize no longer proves that it preserves types. However, we 
can fill in the details by hand using the inferred types of rra and rrf: We 
prove by induction on the type t that the type of |t| is Reify_Reflect([t]i)(f). For 
t = a, we have \t\ = rra which has type Reify_Reflect(Exp(a))(a) as required. 
For t = ti ^ t 2 , we have |t| = rrf(|ti|, |t 2 |)- By hypothesis, \ti\ has type 
Reify_Reflect([ti]i)(ti) for i G {1, 2}. Hence, by the inferred type for rrf we have 
that rrf (|ti| , |t 2 |) has type Reify_Reflect([ti]i ^ [t 2 ]i)(ti — *■ h) as required. As 
a corollary we obtain that for all types t, 

normalize |f| :: [t]i — > Exp(t) 

This proof gives a hint about how to prove (by hand) that typeless type-directed 
partial evaluation preserves types. 
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6.3 Example: Church numerals, typefully 

Let us revisit the example of Section 5.2. We specialize the addition function 
with respect to a fixed argument using the two typeful variants of type-directed 
partial evaluation. In both cases the residual terms are the same as in Section 5.2. 
The Haskell expression normalize |tadd| has type [tadd]i ^ Exp([tadd]i) using 
the first variant and it has type [tadd]i ^ Exp(tadd) using the second variant. 

7 Application 2: Type-directed partial evaluation yields 
normal forms 

In this section, we use the type inferencer of Haskell as a theorem prover to show 
that type-directed partial evaluation yields long beta-eta normal forms. We first 
specify long beta-eta normal forms, both typelessly and typefully (Section 7.1). 
Then we revisit type-directed partial evaluation, both typelessly (Section 7.2) 
and typefully (Sections 7.3 and 7.4). 

7.1 Long beta-eta normal forms 

We consider explicitly typed A-terms: 

(Types) t ::=a \ti^ ^2 
(Terms) e ::= x | cq ci | Xxr.t.e 

Definition 1 (long beta-eta normal forms [3,4]). A closed term e of type 
t is in long beta-eta normal form if and only if it satisfies • hnf e :: t where 
“■ ” denotes the empty environment and where terms in normal form and atomic 
form are defined by the following rules: 



A,x ::ti\~ni e::t2 „ , Z\ hat e :: a 

lam coerce 

Z\ hnf Ax::ti. e :: — > ^2 Z\ h„f e :: a 

A hat eo :: h ^ t2 A h„f Ci :: ti A{x) =t 

[appj [varj 

hat eoci :: t2 Z\ hat a: :: t 

No term containing /3-redexes can be derived by these rules, and the coerce rule 
ensures that the derived terms are fully vy-expanded. 

Figure 6 displays a typeless representation of normal forms in Haskell. Fig- 
ure 7 displays a typeful representation of normal forms in Haskell. 

7.2 Typeless type-directed partial evaluation and normal forms 

We now reexpress type-directed partial evaluation as specified in Figure 8 to 
yield typeless terms, as also done by Filinski [3]. The type of normalize reads 
as follows. 

normalize :: Reify_Reflect(a) ^ a ^ Nf 
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module TypelessNf where 

data Nf_ = AT_ At_ 

I LAM String Nf_ 
data At_ = VAR String 
I APP At_ Nf_ 

type Nf = Int -> Nf_ 
type At = Int -> At_ 

app el e2 x = APP (el x) (e2 x) 
lam f X = LAM v (f (\_ -> VAR v) (x + 1)) 

where v = "x" ++ show x 
at2nf e X = AT_ (e x) 

Fig. 6. Typeless representation of normal forms 



module TypefulNf where 

data Nf_ = AT_ At_ 

I LAM String Nf_ 
data At_ = VAR String 
I APP At_ Nf_ 

data Nf t = NF (Int -> Nf_) 
data At t = AT (Int -> At_) 

app : : At (a -> b) -> Nf a -> At b 

lam : : (At a -> Nf b) -> Nf (a -> b) 

coerce : : Nf a -> Nf (Nf a) 
uncoerce : : At (Nf a) -> Nf a 

at2nf : : At a -> Nf a 

app (AT el) (NF e2) = AT (\x -> APP (el x) (e2 x)) 

lam f = NF (\x -> let v = "x" ++ show x 

NF b = f (AT (\_ -> VAR v)) 
in LAM V (b (x + 1))) 

coerce (NF f) = NF f 

uncoerce (AT f) = NF (\x -> AT_ (f x) ) 

at2nf (AT f) = NF (\x -> AT_ (f x) ) 

Fig. 7. Typeful representation of normal forms 
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module TypelessTdpeNf where 




import TypelessNf — from Figure 6 




data Reify_Ref lect a = 

RR { reify :: a -> Nf, 

reflect : : At -> a } 




rra = — atomic types 

RR { reify = \x -> x, 

reflect = \x -> at2nf x I 




rrf (tl, t2) = — function types 

RR { reify = \v -> lam (\x -> reify 

reflect = \e -> \x -> reflect t2 


t2 (v (reflect tl x) ) ) , 
(app e (reify tl x)) }■ 


normalize t v = reify t v 




Fig. 8. Typeless implementation of type-directed partial evaluation 
with normal forms 



This type proves that type-directed partial evaluation yields residual terms 
in beta normal form since the representation of Figure 6 does not allow beta 
redexes. These residual terms are also in eta normal form because at2nf is only 
applied at base type: residual terms are thus fully eta expanded. 

7.3 Typeful type-directed partial evaluation and normal forms 
(first variant) 

We now reexpress type-directed partial evaluation to yield typeful terms as spec- 
ified in Figure 9. The type of normalize reads as follows. 

normalize :: Reify_Reflect(a) ^ a ^ Nf(a) 

This type proves that type-directed partial evaluation (1) preserves types and 
(2) yields terms in normal form. 

7.4 Typeful type-directed partial evaluation and normal forms 
(second variant) 

On the same ground as Section 6.2, i.e., to bypass the artefactual coercions of 
the typeful encoding of abstract syntax, we now reexpress type-directed partial 
evaluation to yield typeful terms as specified in Figure 10. The type of normalize 
reads as follows. 



normalize :: Reify_Reflect(a)(/3) ^ a — > Nf(/3) 
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module TypefulTdpeNf 1 where 

import TypefulNf — from Figure 7 

data Reify_Ref lect a = 

RR { reify : : a -> Nf a, 
reflect : : At a -> a }■ 

rra = — atomic types 

RR { reify = \x -> coerce x, 

reflect = \x -> uncoerce x }■ 

rrf (tl, t2) = — function types 

RR { reify = \v -> lam (\x -> reify t2 (v (reflect tl x) ) ) , 
reflect = \e -> \x -> reflect t2 (app e (reify tl x)) }■ 

normalize t v = reify t v 

Fig. 9. Typeful implementation of type-directed partial evaluation 
with normal forms (first variant) 



module TypefulTdpeNf 2 where 




import TypefulNf — from Figure 7 




data Reify_Ref lect a b = 

RR { reify : : a -> Nf b, 

reflect : : At b -> a }■ 




rra = — atomic types 

RR { reify = \x -> x, 

reflect = \x -> at2nf x ]■ 




rrf (tl, t2) = — function types 

RR { reify = \v -> lam (\x -> reify t2 (v 

reflect = \e -> \x -> reflect t2 (app e 


(reflect tl x) ) ) , 
(reify tl x)) }■ 


normalize t v = reify t v 




Fig. 10. Typeful implementation of type-directed partial evaluation 
with normal forms (second variant) 
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This type only proves that type-directed partial evaluation yields terms in normal 
form. As in Section 6.2, we can prove type preservation by hand, i.e., that 

normalize |t| :: [t ]2 Nf(t) 

where the instance of a type is defined by 

[a]2 = Nf(a) 

[ti ^2)2 = [ti ]2 ^ [^2)2 

8 Conclusions and issues 

We have presented a simple way to express typed abstract syntax in a Haskell- 
like language, and we have used this typed abstract syntax to demonstrate that 
type-directed partial evaluation preserves types and yields residual programs in 
normal form. The encoding is limited because it does not lend itself to programs 
taking typed abstract syntax as input — as, e.g., a typeful transformation into 
continuation-passing style. Nevertheless, the encoding is sufficient to establish 
two key properties of type-directed partial evaluation automatically. 

These two properties could be illustrated more directly in a language with 
dependent types such as Martin-L6f type theory. In such a language, one can 
directly represent typed abstract syntax and program type-directed partial eval- 
uation typefully. 
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Abstract. We introduce a simply typed A-calculus \ke which has both 
contexts and environments as first-class values. In \ne, holes in contexts 
are represented by ordinary variables of appropriate types and hole fill- 
ing is represented by the functional application together with a new ab- 
straction mechanism which takes care of packing and unpacking of the 
term which is used to hll in the holes of the context. \ke is a conserva- 
tive extension of the simply typed A/3-calculus, enjoys subject reduction 
property, is confluent and strongly normalizing. 

The traditional method of defining substitution does not work for our 
calculus. So, we also introduce a new method of defining substitution. 
Although we introduce the new definition of substitution out of neces- 
sity, the new definition turns out to be conceptually simpler than the 
traditional definition of substitution. 



1 Introduction 

Informally speaking, a context (in A-calculus) is a A-term with some holes in it. 
For example, writing [ ] for a hole. Ay. [ ] is a context, and by filling the hole 
in it with a; -I- y, we get Ay. x + y. By this operation, the variable y in a; -I- y 
gets captured and becomes bound in Ay. a; -b y, and the variable x remains to be 
free. So, unlike substitution, hole filling may introduce new and intended bound 
variables. 

Recently there have been several attempts to formalize the notion of context 
and thereby make computing with contexts possible. For example, Talcott [16], 
Lee-Friedman [8], Dami [5], Hashimoto-Ohori [7], Sands [13], Mason [9] and 
Bognar-de Vrijer [3] made notable contributions. However, as far as we know, 
there is as yet no proposal of a language which has contexts as first-class values 
and which is at the same time pure in the following sense. We understand that a 
functional language is pure^ if (i) it is a conservative extension of the untyped or 
simply typed A/3-calculus, (ii) confluent and (iii) strongly normalizing (SN) if the 
language is typed and has preservation of strong normalization (PSN) property 
if the language is untyped. The conservative extension property guarantees that 

^ We have introduced this notion of purity in [15]. 

H. Kuchen and K. Ueda (Eds.): FLOPS 2001, LNCS 2024, pp. 359-374, 2001. 
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the language is logically well-behaved and the confluence property and SN or 
PSN would guarantee that the language is computationally well-behaved. 

In this paper, we introduce the calculus \ne {k is for context and e is for 
environment) which is pure in the above sense and which has contexts and envi- 
ronments as its first class values, so that we can bind contexts and environments 
to variables and return them as the values of computations. Xne is a simply 
typed calculus, and in Xk£, holes are represented by ordinary variables of appro- 
priate types (which we will call hole types) and hole filling is represented by the 
functional application together with a new abstraction mechanism which takes 
care of packing and unpacking of the term which is used to fill in the holes of 
the context. 

We now illustrate some of the difficulties we face in formalizing the notion 
of context, and explain our solution informally by relating it to previous works. 
First, let us consider the context: 

o[ ] = Xx. {Xy. X -1- [ ])3. 

If we fill the hole in a[ ] with the term a; -I- y, we get 

a[a; + y] = Xx. {Xy. x + {x + y))3. 

By /3-reducing it, we can convert a[x + y] to Xx. x + (a; -|- 3). Since we wish to 
compute with contexts, we would also like to reduce the /3-redex {Xy. a: -I- [ ])3 
in a[ ]. If we reduce it naively, we get a; -I- [ ], so that a[ ] reduces to Aa:. a; -I- [ ]. 
Now, if we fill the hole in Xx. a; -I- [ ] with a; -I- y, we get Xx. x + {x + y). This 
shows that hole filling and /3-reduction do not commute if we define hole filling 
and /3-reduction as above. In this example, we can note that the hole in the 
original context a[ ] is within the scope of Xx and Ay, while the hole in the 
/3-reduced context is only within the scope of Aa;. This means that a part of the 
information as to which variables should be captured at the hole is lost if one 
reduces a /3-redex which has a hole in it. Hashimoto-Ohori [7] did not solve this 
problem. Instead they put restriction on the /3-reduction rule in their system 
and prohibited such /3-reductions like the above example. 

To solve this problem, we introduce the type which represents the set 
of objects obtained by abstracting objects of type A with respect to a set 33 = 
{x \, . . . , Xn} of variables. Canonical objects of type A^ are abstracts of the form 
kE. a where a is of type A and the kE binder declares that the variables in E 
should be understood as local in a. Moreover, E is also a type and its canonical 
elements are environments of the form {a\/xi , . . . , a„/a;„}. Then, an object a of 
type A^ can be instantiated to an object b of type A by applying the abstract 
a to an environment e = {ai/x \, . . . , a„/a;„}. We write a-e for the application 
of the abstract a to the environment e. For example, {k{x, y}. a; -|- y)-{l/a;, 2/y} 
can be reduced to 3. 

In this setting, we can represent the above context a[ ] as 



C = Xx. {Xy. X + X-{x/x,y/y))i 
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where X represents the hole and its type is of the form Now, suppose 

that we wish to fill the hole X with the term x + y. Then, we can achieve this 
hole filling by substituting K{x,y}. x + y ior X in C. By this substitution, we 
have: 

D = Xx. {Xy. x + {K{x,y}. x + y)-{x/x,y/y})3. 

D can be reduced to Xx. {Xy. x + {x + y))3, which can be further reduced to 
Xx. a: + (x + 3) as expected. Let us now see what happens if we reduce the 
/3-redex in C first and then fill the hole with x + y. By /3-reducing C, we get 
Xx. X + X-{x/x, 3/y}. Substituting n{x, y}. x + y for X in this term, we have 

Xx. X + {k{x, y}. X + y)-{x/x, 3/y}, 

which we can further reduce to Xx. a; + (a; + 3). We can thus see that hole filling 
and /3-reduction commute in this case. 

The idea of decorating a hole with an environment is due to Talcott [16], 
and Mason [9] also used this idea in his calculus of contexts that has contexts as 
first-class values. However, in Mason’s system, environments appear in a term 
containing holes only as annotations. This means that such environments are 
objects outside the system. We present our calculus Xne as an extension of 
Ae [15] which is a simply typed A-calculus that has environments as first class 
values. So, environments are first-class objects in Xke. Moreover, Mason defines 
hole filling only as a meta-level operation. Therefore, although contexts are first- 
class values in his system, one cannot compute hole filling within his system. In 
contrast to this, we can compute hole filling within our system. For example, we 
can express the above example of filling a[ ] with x + y as follows: 

(AX. Xx. {Xy. X + X-{x!x, y/y})3){K{x, y}. x + y). 

We can compute the above term in Xne, and we get Xx. x -I- (a; -I- 3) . 

We now turn to another problem in the formalization of contexts. Consider 
the informal context Xx. [ ]. If we fill the hole in this context with x, we get 
the term Xx. x. This term is a-equivalent to Xy. y. What is the context which 
is a-equivalent to Xx. [ ] and which, when filled with x, becomes Xy. yl It is 
certainly preferable that such a context exists, since, otherwise, hole filling and 
a-conversion will not always commute. A naive attempt is to a-convert Xx. [ ] to 
Xy. [ ]. But this does not work, since filling Xy. [ ] with x results in Xy. x which 
is not a-equivalent to Xy. y. We can solve this problem easily in our setting as 
follows. In Xne, the context Xx. [ ] is written as Xx. X-{x/x} and this context 
is a-equivalent to Xy. X-{y/x}. Filling these holes in these two contexts with 
X is achieved by substituting k{x}. x for X in these contexts, and the results 
are Xx. («:{a;}. x)-{x/x} and Xy. {k{x}. x)-{y/x} respectively. Then they are 
reduced to Xx. x and Xy. y as expected. 

In this paper we also introduce a new method of defining substitution. As 
we explain below, the traditional method of defining substitution does not work 
for our calculus. We are therefore forced to use the new method, but, we believe 
our new definition of substitution is mathematically cleaner than the traditional 
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method of defining substitution. We now give an example where the traditional 
method of defining substitution fails to work. By way of comparison, we first 
consider the A term a = Xx. x + y. What is the result of substituting x for y 
in a? We must be careful enough to avoid the variable clash and rename the 
bound variable a; in a to a fresh variable, say, 2 :, and we get A 2 . z + x as the 
result of the substitution. Now consider the abstract b = k{x}. x + y. What 
will be the result c of substituting x for y in 6? If we perform substitution by 
the same method as above, we get k{z}. z + x which is wrong for the following 
reason. Note that b-{2/x} reduces to 2 + y. So, c-{2jx\ must reduce to 2 + x. 
However, we cannot reduce {k{z}. z + x)-{2/x} since the argument {2/x} does 
not match the binder k{z}. By the same token, the term {k{z}. z + x)-{2/x} 
is not even typable. We can thus see that, unlike variables bound by the A 
binder, we cannot rename variables bound by the k binder. To cope with this 
situation, we introduce a new method of dehning substitution where we rename 
free variables (if necessary) to achieve the capture avoiding substitution. So, our 
substitution will yield k{x}. x + '^x as the result of substituting x for y in b, 
where '^x in the scope of the k{x} binder is a renamed form of the free variable 
X and it stands for the free variable x. 

The paper is organized as follows. In section 2, we introduce the type system 
of Xne, and introduce derivation rules that are used to dehne (typed) terms 
together with their types and free variables. There, we dehne variables so that 
they naturally contain both ordinary variables with names and variables as de 
Bruijn indices. In section 3, we dehne substitution as a meta-level operation. In 
section 4, we give reduction rules of Xne and give some examples of computations 
in Xk£. In section 5, we show that \k£ enjoys a number of desirable properties 
such as conhuence and strong normalizability. In section 6, we give concluding 
remarks. Due to lack of space, we have omitted almost all proofs. A full version of 
this paper with proofs is accessible at http : //www . sato . kuis . kyoto-u .ac.jp/ 
"masahiko/ index-e . html. 

2 The Type System 

In this section, we dehne the type system of Xk£ by dehning the notion of a 
derivation of a typing judgment. A typing judgement is an expression of the 
form T h a : A, and if it is derivable then it means that the expression a is a 
term whose type is A and whose set of free variables is F. 

In the following we assume that we have given a hnite set of atomic types 
which we do not specify further in this paper. We also assume that we have 
inhnitely many identifiers (i). Then, we dehne variables and types simultaneously 
as follows. 

A variable (we will use x, y, z, u, v as meta-variables for variables) is a triple 
{k,i,A) where fc is a natural number, i is an identiher and A is a type. A 
variable {k,i,A) is called a pure variable ii k = 0. Types (A,B) are dehned by 
the following grammar: 

A,B ::= K \ E \ B \ 
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where K ranges over atomic types and E over finite sets of pure variables. 

In the following, we will use declaration as a synonym for a finite set of 
variables and pure declaration as a synonym for a finite set of pure variables. 
We use r, A etc. as meta variables for declarations and E, F as meta variables 
for pure declarations. A pure declaration {x\, . . . ,Xn} will also be called an 
environment type since it is the type of environments whose canonical forms are 
elements of the form {ai/xi, . . . ,a„/a;„}. 

If cc = {k, i, A), then we call k the level of x, i the name of x and A the type 
of X. In this case, we sometimes write x^ for x and also write ft* a: for {k + l,i,A), 
'^x for and x for (0,i, A). 

We write V for the set of all the variables. Let E he & pure declaration. We 
define a function -fl-^ : V — ^ V — i? by 'f|"®(a;) :=jla; if x C and 'f|'^(a;):=a; if a; ^ E. 
We also define IJ-e as the inverse function of 'ff^. Note that JJ-E(a;) is defined only 
when X ^ E. For example, if E is empty, then 'f|"®(a;) = x for any variable x. If 
E is {x,y}, then tr^(a;) = fa;, tl^(f a;) = fx, = 2 , = fa;, and 

is undefined. We will use 'ff® later to systematically rename variables to 
avoid collision with the variables in E. 

Let r be a declaration and E, F be pure declarations. We define the decla- 
rations r 'fl'^ and r IJ-E as follows: 

:= {^""(a;) | a; G P}, E^ ■= Ua;(a;) | a; G P}, 

where P JJ-e is defined only when P n P is empty. Furthermore, given two decla- 
rations E and P, we define a function : V ^ V as follows. 

( i[^{x) if a; G P, 

(a;) ;= < |lE(a;) if a; G Pfr^, 

[ X otherwise. 

We give a few examples here. If P is {a;}, then l):f(a;) = t|a;, Ijf (jla;) = x, 
and l):f(fa;) = fa;. If P is {x,y} and P is {a;}, then l):f(a;) = jja;, = x, 

t-piy) — the next section, we will use to 

rename variables when the order of two binders are exchanged. 

Using the function , we define the declaration Pljf as follows. 

rtf := {$f(a;) I a; G P}. 

Lemma 1. We have the following equations. 

1 . Pfr^nP = 0. 

2 . rt^tE = r. 7/pnp = 0, thenrtEt^ = r. 

3. ((P -E)tE- F)tE = ((P^U - P)^F - E)tE- 

A typing judgment is an expression of the form P h o : A where P is a 
declaration and A is a type. We have the typing rules in Figure 1 that are used 
to derive typing judgments, where those rules whose names end with ‘J’ (‘P’) 
introduce (eliminate, respectively) the types mentioned in the rule names. 

An expression a is said to be a term if a typing judgment of the form P h a : A 
is derivable for some P and A. In this case, we say that P is the set of free 
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{x} h x^ : A 



(axiom) 



rhb:B 

(r - h b-.A^B 






r \- b : A ^ B A\- a : A r p-. 
ruA\-ba:B ^ ’ 



r\-a: A 

{r - E)i}.E\- kE. a : A^ 



(abs/) 



r\- a: A^ Ah e: E 
r \J A\- a-e A 



(absiJ) 



E\ : Al • • • Eji \~ Un • An , 

A 1 (envj 

A U . . . U r„ h {ai/a:f\ . . . ,an/Xn"} ■ {xi,. . . ,Xn} 

E \- e : E A\- a \ A / 

^ IT";; (enviS) 

ru{A-E)i).E^ela\-.A^ ' 

In (=>/), the variable x must be pure. 

In (env/), the variables xi, . . . ,Xn must be pure and mutually distinct. 
Fig. 1. Typing rules of Xke 



variables in a and write FV (a) for it and also say that A is the type of a and write 
TY(a) for it. Note that if e = {ai/xi , . . . , a„/a;„}, then TY(e) is {x\, . . . , x„}. 
We will say that these variables are bound by e. We also write T for the set of 
all the terms. A term is eanonical if it is of the form Xx.b, {ai/a:i, . . . , a„/a;„} or 
kE. a, that is, if it is obtained by one of the introduction rules. A term is said 
to be an environment term if its type is an environment type. 

In (=^/), since free variables in b are within the scope of Xx"^, should 
be applied to F — {a;} to refer to the variables in b from the outside of the 
binder. By the same reason, IJ-b is used in (absJ) and (envF). We have explained 
the intuitive meaning of the typing rules (abs/) and (absF) for introducing and 
eliminating abstractions in section 1. The remaining typing rules come from Xs, 
and the reader is referred to [15] for the detailed explanation of these rules. Here, 
we only remark that the term e|a] in the (env/?) rule means to evaluate a in the 
environment e. So, for example, if e = {Xx. Xy. x + yjz, 1/x, 2/u}, then e| 2 a:y] 
is evaluated to 1 + y. Note that ^ and x in zxy are bound by e and y is free in 
elzxyj. 

We give below a simple example of a derivation. In the example below, we 
assume that x and y are distinct pure variables. 



{y}\- y : B 



(axiom) 



{Da;} h Da; : A 



{yAx} b y(Da;) : A^ B 



(axiom) 

i^E) 



{a;} \- X : A 






{y, pa;, a;} h yAx)x : B 
{y, x} h Aa;. y(ix)x : A=> B 
{} h K{x,y}. Xx. yAx)x : {A B)^^'A 



(abs/) 



(axiom) 

i^E) 
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It is easy to see that if _T h a : A is derivable, then we can completely recover 
the entire derivation tree uniquely by inspecting the typed term a^. 

We have two kinds of abstractions A and k — A abstracts nameless variables 
and K abstracts named variables. We can eliminate A by taking the distinguished 
named variable i, replacing A by k{l}, and using the de Bruijn index method 
that we explain in the next section. But we did not do so, because we want to 
design Xne so that it extends the traditional A-calculus directly. (See also the 
comments at the end of section 3.) 



3 Substitution 

In this section we define substitution as a meta-level syntactic operation. Our def- 
inition is conceptually simpler than the ordinary definition of substitution where 
a-conversion is sometimes necessary to avoid the unwanted capture of variables. 
Our method of defining substitution is a simple extension of the method due to 
de Bruijn [4]. 

Before going into technical details, we explain our method by comparing 
it with the traditional method of defining substitution for terms with named 
variables [1] and also with the method invented by de Bruijn [4] . In the traditional 
method, for example, substitution of x for y in Xx. y is done by first a-converting 
Aa:. y to, say, Xz. y and then replacing y by x. Thus, the result of substitution 
is Xz. X. The a-conversion was necessary to avoid unwanted capturing of x by 
the Aa; binder in the original term. So, in this approach, one has to define terms 
as equivalence classes of concrete terms modulo a-equivalence, and therefore, 
we have to check the well-definedness of the substitution, since we first define 
the substitution operation on concrete terms. Also, in this approach, one has 
to define a-equivalence before substitution, but the definition of a-conversion 
requires the notion of renaming variables which is similar to substitution. 

We think that such complication in the traditional definition of substitution 
comes from the fact that avoidance of capturing free variables was achieved by 
the renaming of the name of the A-binder. Our approach here is to avoid the 
capture of free variables by systematically renaming the free variables which 
would otherwise be captured^. For instance, in case of the above example of 
substituting x for y in Xx. y, we rename x to jja; and substitute jja; for y, so that 
the result of the substitution becomes Xx. '^x. We note that in the resulting term 
Xx. tta;, the variable jja; is different from x within the scope of Xx, and that fa; 
refers to x outside the scope of Xx. From this explanation, it should be easy 
to understand that the result of substituting a; * 2 : for y in Aa;. Xx. x + y is 
Xx. Xx. X + (jl^a; * z). As can be seen from this example, we rename only those 
variables that would otherwise be captured. Therefore, in case capturing does 

^ Strictly speaking, in order to have this property, we have to identify those derivations 
which are the same up to the difference of ordering of the premises of the (envJ) 
rule. 

® We have introduced this idea of renaming free variables in [14] . 
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not occur, the result of substitution obtained by our method is the same as that 
obtained by the traditional method. 

We give another example to clarify the intuitive idea. Suppose that x, y, z 
are distinct pure variables. Then the following terms are all a-equivalent with 
each other. 



Xx. Xy. {Xz. y{zx)){yx) 

=a Xfx. Xfx. {Xf'x. '^^xifx fx)){fx fx) 

=a Xx. Xy. {Xx. y{x ^x)){yx). 

If we write 0, 1 and 2 for ft^a; and respectively, in the second term above, 
we get AO. AO. (AO. 1(02))(01). Therefore, this term is essentially the same as 
the representation of the first term in de Bruijn indices. We can therefore see 
that our terms are natural extensions of both traditional concrete terms with 
variable names and name free terms a la de Bruijn that use indices. 

Let 0 : V — > V be a (possibly) partial function such that (p{x) may be 
undefined for some a; G V. We extend this function to the function 0 : T ^ T as 
follows, (j) will be total if and only if (p is total. 

1. 1{x):=(j>{x). 

2. <p{Xx. a) := Xx. <pfx}(d)- 

3. 4>{ba) := (p{b)4){a) . 

4. (P{kF. a) := kF. (pp{a). 

5. ~p{a-f) :=p{a)-p{f). 

6. p{{ai/xi, .^. , g „/a:„}) := {(p{ai)/xi, ..., </>(a„)/a;„}. 

7. (plelal) :=4>ie)[4>TY{e){a)l 

where, for each declaration Li, 0^; : V ^ V is defined by 
, . s fa; if a; G £^, 

(pE(X) . I 

(We note that if (p is not total, pE is also not total.) 

We define the push operation by putting at'® :=lt®(a), the pull operation 
Ie by putting ais ^fj- £;(«), and the exchange operation by putting at® := 

11(a)- 

Let us give a few examples here. Let E be {x,y}. 

{Xx. a;(fa;))T® = lt®(Aa;. x{fx)) 

= ^x. {^}{x{f x)) 

= ^x. (It®{,,}(a;))(tr^{,,}(fa;)) 

= Aa;. a;(lt^"^^tr®tl{,,}(fa;)) 

= Xx. a;(jl^a;). 

Note that FV(Aa;. x{f'x)) = {{i^x}, and {(t^ajlti® = {ft^a;}, which is equal to 
FV(Aa;. x{^'^x)). Similarly, we have (Aa;. x{f'x))[E = Xx. a;(U^a;). 
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For the exchange operation, we have: 

{Xx. = Ax. (fx)(|Jx), 

(Ax. (tlx)(t|2x))||^| = Ax. (ttx)(tl^x), 

where x and y are distinct pure variables. 

We now define the substitution operation as follows. Let s = {ci/xi,..., 
Cn/xn} be a canonical environment term. Note that TY(s) = {xi,...,x„} in 
this case. For each term a we define a term a[s] inductively as follows. (We think 
that the 2nd clause below corresponds to the 2nd clause of the definition of the 
substitution operation a : 6Ay, A ^ A m Fiore-Plotkin-Turi [6], and we think 
that it should be possible to establish a precise correspondence.) 

.. r , j Ci if X = Xi for some i, 

x[sj . I jj,.j,Y(s)(x) otherwise. 

2. (Ax. 6)[s] := Ax. 

3. (6a)[s] := &[s]a[s]. 

4. {kE. a)[s]:= kE. 

5. (a-e)[s] := o[s]-e[s]. 

6. ({ai/xi, . . . , a„/x„})[s] := {ai[s]/xi, . . . , a„[s]/x„}. 

7. (eH)W:=eMI(a|^^;:j)[sT^^(^)]l. 

We call a[s] the result of substituting Ci, . . . , c„ for Xi, . . . , x„ in a. 

Again we give a few examples. Let s be {(t^x/y, (x Ux)/x}. Then we have: 

(Ax. X Ux)[s] = Ax. (x 

= Ax. (t|x x)[{jj'‘x/y, (j)x H^x)/x}] 

= Ax. (l|{j;,x}tla;)(ttx jj^x) 

= Ax. x(t|x tt^x), 

(Ax. xy)[{z/y}] = Xx. xz, 

where x, y, z are distinct pure variables. 

In the first example, x in Ax. x ftx is bound by Ax and jjx is bound by s. 
When s goes into the scope of Ax, x and j)x should be renamed to ftx and x, 
respectively so that they are bound by Ax and 

We can now define the a-equivalence using substitution as follows. 

1. X =Q, X 

2. If a[{z/x}\ =a a'[{z/x'}\, then Ax. a =a Xx' . a' where 2 : is a variable such 
that 2 ^ FV (a) U FV (o') U {x, x'}. 

3. If b =a b' and a =a a' , then ba =„ b'a' . 

4. If a =01 a! , then kE. a =a kE. a' . 

5. If a ~a o! and e =q, e', then a-e =a a! -e! . 

6. Ifui=Q,U2^,***, (Xn =a then {U-i/xi , . . . , U^/Xyi} =a {c^-l/Xi, . . . , Ctn / Xn^ • 
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7. If a =a a' and e =„ e' , then e|a] =a e'|a']. 

Note that variables bound by k are not renamed in the 4th clause because k 
abstracts named variables. On the other hand, variables bound by A may be 
renamed in the 2nd clause bacause A plays the same role as A in the traditional 
A-calculus. 



4 Reduction Rules 

In this section we give reduction rules of the Xne calculus. We first define i— 
as the union of the following three relations i— and i— >£. 

The relation is defined by the following single rule: 

(A) {Xx.b)ai-^x{a/x}lbj, 

and the relation is defined by the following single rule: 

(k) {kE. a)-e I— e|a]. 

The relation is defined by the following 8 conversion rules. 

(gc) e|a] aiTY(e), if TY(e) n FV(a) = 0. 

(var) {ai/xi,..., an/xn}{xil di {I <i < n). 

(fun) e|Aa;. bj Xx. 

(funapp) e|6a] e|6]e|a]. 

(abs) e{KE. a] kE. 

(absapp) e|a-/l e|a]-e|/]. 

(env) e{{ai/xi, a„/a;„}| {e|ai]/a;i, . . . , e|a„]/a;„}. 

(eval) elflxJl e|/]|x]> if G TY(/). 

The rules other than (eval) are internalized forms of the clauses 1-6 of the 
definition of substitution in section 3. In these rules we have the environment 
term e in place of the canonical environment term s, and the rule (gc) is a 
generalization of the second case of clause I. We can also internalize clause 7 
directly and get a correct rule. But, we do not do so since it will result in a 
system where the strong normalization property does not hold. Instead we have 
the (eval) rule which corresponds to a special case of clause 7. Although the 
(eval) rule is a weak version of clause 7, we will see in Theorem I that we can 
faithfully compute substitution internally by using these reduction rules, and at 
the same time the system enjoys the strong normalizability (Theorem 6). In fact, 
as can be seen in, e.g., Mellies [10] and Bloo [2], the strong normalizability of 
calculi of explicit substitutions and explicit environments is a subtle problem. 
The reader is referred to [15] for a detailed discussion on our choice of the (eval) 
rule. 

We write a biibis obtained from a by replacing a subterm c in a by c? such 
that c I— d. Similarly and — s-aks are defined. The transitive closures 

of these reductions are denoted with asterisk (*), such as — >£. The equivalence 
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relation generated by is denoted by =\K.e, namely, the reflexive, symmetric, 
and transitive closure of Similarly =£ is defined. 

We give a few examples of reduction sequences. Let s = {{x '^^x/y} 

in the second example. 



{\x. Xy. x)y ^A {y/x}{Xy. a;] 

Xy. {{y/x}^^y^)ixi\;\i 
= Ay. {tty/a;}|a;] Xy. fty. 

s|Aa;. X Ux] Ax. (st^"^^)[(x 

= Ax. {(jlx fx)/x, tt^x/y}|(ttx x)] 

Ax. (l|{a:,y}jla;)(jjx fx) 

= Ax. x(ttx U^x). 

(AX. Xy. X-{y/y}){K{y}. y) {n{y}. y/X}|Ay. X-{y/y}j 

Xy. {K{y}. y)-{y/y} 

Ay. {y/y}[yl Ay. y. 

In the first example, y is renamed to jjy so that it is not captured by the Ay 
binder. The second example corresponds to the example given after the definition 
of substitution. The third example shows the hole-filling operation where y is 
captured by the Ay binder. 

We take an example from Hashimoto-Ohori’s paper [7]. Consider the term 
{Xz. C[x -\- z\)x where C is an (informal) context (Ax. [ ] -I- y)3 and C[x + 
z] represents the hole-filling operation in the A-calculus. In Hashimoto-Ohori’s 
calculus, this term can be written as 

a = {Xz. {6X.{Xu. Xi“/"} + y)3) ©{,/„} (x + z))x 

where X represents a hole, 6X abstracts the hole X, and © is a hole-filling 
operator, {u/x} and {x/v} (called renamers) annotate X and © respectively. 
They are introduced to solve the problem of variable capturing. In our system, 
the above term can be written as 

a = {Xz. (AX. {Xu. X-{u/x} + y)3){n{x}. (x -|- z)))x. 

We can compute this term in many ways, but, here we give two reduction 
sequences. 

a — >A {x/^}|(AX. {Xu. X-{u/x} + y)3)(At{x}. x -I- 2 ;)] 

(AX. {Xu. X-{u/x} + y)3)(At{x}. x -|- j)x) 

^A {k{x}. X + ttx/X}|(Au. X-{u/x} + y)3] 

{Xu. {k{x}. X + Ux)-{'u/x} -I- y)3 
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(Am. {u/x}lx + ttx] + y)3 

(Aw. u + X + y)3 

{3/w}[[u + x + yj^eS + x + y. 

a {\z. (AX. {3/w}|X-{w/a;} + t/])(K{a;}. x + z))x 
{\z. (AX. X-{3/x} + y){K{x}. X + z))x 
{Xz. x + 2/X}|X-{3/a;} + yj)x 

(A^. {k{x}. X + z)-{‘ilx} + y)x 
{Xz. {3/a;}|a; + zj+ y)x 
{Xz. ?> + z + y)x 
{x/z}{^ + z + y\ ^e^ + x + y. 

We remark that, in the second reduction sequence above, we have first reduced 
the innermost /3-redex {Xu. X-{w/a;} + y)i. Such a reduction is not possible in 
Hashimoto-Ohori’s calculus since in their system the /3-conversion is prohibited 
when the redex contains a free hole. Though the roles of and X-{u/x} 

are similar, u in should always be a variable, while u in X-{w/a;} can be 

substituted by an arbitrary term. This is the reason why our calculus need not 
put any restriction to the (A)-reduction rule (the /3-conversion). 

We also remark on the hole-filling operations without going into the technical 
details. In Hashimoto-Ohori’s calculus, the renamer iz in works as a variable 
binder to the second operand of 0 (i.e. to the term to be filled into the hole). 
Because their typing rule of M ©^ X causes a side effect to the type of the free 
hole in N, they had to put the restriction that each free hole may occur at most 
once. Our kE binder, which plays the similar role to the renamer p in Q^, does 
not have such a problem, because it is merely an abstraction. 

Therefore, our calculus Xks can be regarded as a natural and flexible exten- 
sion to Hashimoto-Ohori’s calculus. 

5 Properties of Xks 

In this section, we show that Xne enjoys a number of desirable properties. We first 
show that the meta-level operation of substitution is internally realized by the 
operation of evaluation (Theorem I), and show some properties of substitution. 
We also show that Xne enjoys subject reduction property (Theorem 3), conflu- 
ence property (Theorem 4), conservativity over the simply typed A/3-calculus 
(Theorem 5), and strong normalizability (Theorem 6). Theorems 4-6 establish 
the purity of Xne, and as a corollary to the confluence of Xne, we see that the 
operations of hole filling and /3-reduction always commute. 

As we have studied in [15], we can internalize the meta-level operation of 
substitution by means of evaluation terms which are of the form e|aj. We can 
show that the meta-level substitution and the internalized substitution coincide, 
that is, a[s] =«£ s|a] holds. 




A Simply Typed Context Calculus with First-Class Environments 371 



Theorem 1. Let s be a canonical environment term. Then, for any term a, 
a[s] =KE s|a] holds. 

Lemma 2 corresponds to the Substitution Lemma [1] in the A-calculus, that 
is, M[x := K][y := L] = M[y := L][x := K[y := L]] if x ^ y and x ^ FV(L). 

Lemma 2 (Substitution Lemma). Let s and t be canonical environment 
terms. Then, for any term a, a[s][t] = holds. 

Note that the effect of exchanging the order of two substitutions s and t is 
adjusted by applying the exchange operation |^y(s) ® push operation 

-j-TY(s) Pqj. example, let a be a; jjx, s be {z/x}, and t be {jj^x/y, (a; f),x)/x} 
in the Lemma. Then, we have 

(a; Ua;)[s][t] = {z x)[t] 

= z {x tta;), 

(x = iix x)[{fx/y, (jja; tt^a;)/a;}][s[t]] 

^ (x (tta: fx))lU/x}] 

= z ((tta: tt^a:)i{^}) 

= z {x tta:). 

(See also the example below the definition of the substitution in seciton 3.) 

The reduction is compatible with substitution. 

Theorem 2. If a b, then a[s] ^ake b[.s]. 

The following theorems will establish the purity of our calculus. 

Theorem 3 (Subject Reduction). If T \- a : A and a — >ake b, then A\- b : A 
for some ACT. 

Theorem 4 (Confluence). — >ake on Xns-terms is confluent. 

Proof. The proof is a straightforward extension of that for Xs, and we omit the 
details here. 2 

We remark that from the confluence of Xks, we see that the operations of hole 
filling and /3-reduction always commute, since in Xks, hole filling is computed 
by reducing a term of the form (AX. a){nE. b). 

We next prove that Xks is a conservative extension of the simply typed 
lambda calculus A/3. For this purpose, we embed the A/3-terms in the AK£-terms. 
A A/3-term is a A/te-term such that its typing derivation uses the (axiom), (^/), 
i^E) rules only, and all the variables used in the (axiom) rule are pure variables. 
The a- and /3-conversions over A/3 terms are defined as usual. 

Theorem 5 (Conservativity). Let a and b be X(3-terms. We have a b in 
A/3 if and only if a ^ake b' and b =„ b' for some term b' in Xks. 
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Proof. (Only-if part) easily follows from the fact that the /3-conversion can be 
simulated by the Ae-reduction rules up to the a-equi valence. 

(If-part) can be proved in the same way as in [15], which uses the translation 
from Ae-terms to A/3-terms. 2 

Theorem 6 (Strong Normalizability). If P \- a : A, then a is strongly nor- 
malizable. 

Proof. We can prove this theorem in the same way as the strongly normalizability 
theorem of Ae [15], because we can treat the cases of (abs) and (absapp) similarly 
to the cases of (fun) and (funapp). 2 

6 Conclusion 

We have introduced a simply typed A-calculus which has both contexts and 
environments as first-class values. We have shown that our calculus, Xne, is a 
conservative extension of the simply typed A/3-calculus, enjoys subject reduction 
property, is confluent and strongly normalizing. Thus we have shown that our 
language is pure in the sense of [15] and also we have realized our hope, which we 
stated in the conclusion of [15], to design a pure language that has both contexts 
and environments as first-class values. To the best of our knowledge, Xne is the 
first such language. 

We have also introduced a new method of defining substitution which is 
conceptually simpler than traditional methods. We think that our method is also 
suitable for representing terms and computing substitutions on the computer. 

We conclude the paper by comparing our calculus with some related works. 
The style of the presentation of our paper is very close to that of Hashimoto- 
Ohori [7]. Both our calculus and the calculus presented in [7] are simply typed 
calculi which include simply typed A/3-calculus as their subcalculus. The system 
in [7] enjoys subject reduction property and is confluent. However, neither con- 
servativity over simply typed A/3-calculus nor strong normalizability are shown 
in the paper. Therefore, it is not known whether their system is pure in our 
sense^. Also, their calculus has severe restrictions in that (i) each context may 
have at most one hole in it, and (ii) as we have explained in section 1, the appli- 
cation of the /3-reduction is allowed only when the /3-redex has no hole in it. Our 
calculus does not have such restrictions and /3-reduction and hole-filling always 
commute. 

Dami’s calculus XN [5] is a very simple and powerful calculus with named 
variables. It is possible to represent both contexts and hole-filling in XN. How- 
ever, this is done by a translation of A/3 calculus into XN. Therefore, it is hard to 
read the translated terms as contexts. On the other hand. Mason [9] introduces 
a system with first-class contexts in which contexts are directly represented as 
terms in his calculus. However, he defines hole-filling as a meta-level operation. 

^ Sakurada [12] proved the strong normalizability of Hashimoto-Ohori’s calculus by 
interpreting it in Ae. 
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It is therefore not possible to compute hole- filling within his system. Unlike these 
systems, in \ne, contexts are directly representable as terms of A/«e, and we can 
compute hole-filling within Atte. 

Sands [13] uses Pitts’ [11] definition of contexts and shows that hole-filling 
commutes with many relations on terms including a-equivalence. Pitts defines 
contexts by representing holes by (higher-order) function variables where each 
function variable has a fixed arity, and by representing hole- filling by substitution 
of a meta-abstraction for a function variable. For example, the term 

\x. {Xy. X + X-{x/x, y/y})^ 
in Xne can be expressed by 



Xx. {Xy. x + ^{x,y))3 

where ^ is a binary function variable, and the substitution 

{K{x,y}. x + y/X} 



in Xks can be expressed by 



[{x,y){x + y)/(\. 

As can be seen by this example, Pitts’ representation of contexts is structurally 
similar to ours, but the statuses of contexts are quite different. That is, Pitts’ 
contexts are meta-level objects outside the object language (A calculus in case of 
the above example) and our contexts are internal objects of our language Xne. 
Because of this meta-level status of Pitts’ contexts. Sands [13] could successfully 
attach contexts to many languages and could prove that hole-filling commutes 
with many rules in a uniform way. In contrast to this, we have been interested 
in internalizing such meta-level objects as contexts and environments so that we 
can enrich A-calculus to a more powerful programming language. 
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Abstract. The Barendregt Cube (introduced in [3]) is a framework in 
which eight important typed A-calculi are described in a uniform way. 
Moreover, many type systems (like Automath [18], LF [11], ML [17], 
and system F [10]) can be related to one of these eight systems. Further- 
more, via the propositions-as-types principle, many logical systems can 
be described in the Barendregt Cube as well (see for instance [9]). 
However, there are important systems (including Automath, LF and 
ML) that cannot be adequately placed in the Barendregt Cube or in 
the larger framework of Pure Type Systems. In this paper we add a 
parameter mechanism to the systems of the Barendregt Cube. In doing 
so, we obtain a refinement of the Cube. In this refined Barendregt Cube, 
systems like Automath, LF, and ML can be described more naturally 
and accurately than in the original Cube. 



1 Introduction 

In [3], Barendregt proposes a framework, now often called the Barendregt Cube, 
in which eight important and well-known type systems are presented in a uni- 
form way. This makes a detailed comparison of these systems possible. The 
weakest systems of the Cube is Church’s simply typed A-calculus A^- [7], and 
the strongest system is the Calculus of Constructions AC [8]. Girard’s well- 
known System F [10] figures on the Cube between A^- and AC. Moreover, via 
the Propositions-as-Types principle (see [13]), many logical systems can be de- 
scribed in the systems of the Cube, see [9]. 

In the Cube, we have in addition to the usual A-abstraction, a type forming 
operator 77. Briefly, if A is a type, and B is a type possibly containing the 
variable x, then Ux.A.B is the type of functions that, given a term a : A, 
output a value of type B[x := a]. Here a : A expresses that a is of type A, 
and B[x := a] means the result of the substitution of a for a; in B. If a; does 
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Dutch research council NWO. 

** Kamareddine is grateful to Eindhoven University of Technology for its hospitality 
and support during the preparation of this article. 
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not occur in B, then IIx.A.B is the type of functions from A to B, written 
A ^ B. To the //"-abstraction at the level of types corresponds A- abstraction at 
the level of objects. Roughly speaking, if M is a term of type B {M and possibly 
B containing x), then Xx:A.M is a term of type Ux.A.B. The Cube has two 
sorts * (the set of types) and □ (the set of kinds) with * : □. If A : * (resp. 
A : □) we say A is a type (resp. a kind). All systems of the Cube have the same 
typing rules. "What distinguishes one system from another however is the set R 
of pairs of sorts (si,S 2 ) allowed in the so-called type-formation or B -formation 
rule, simply referred to as the rule {II). Each system of the Cube has its own 
set R (which must contain (*,*)). A //-type can only be formed in a specific 
system of the Cube if rule (//) is satisfied for some (si, S 2 ) in the set R of that 
system. The rule (//) is as follows: 



(n) 



r \- A ■. si r,x:A \- B : S 2 
r h {nx:A.B) : S2 



(si,S2) G R 



Note that as there are only two sorts, * and □, and as each set R must 
contain (*, *), there are only eight possible different systems of the Cube. "With 
the rule {II), an important aspect of the Cube is that it provides a factorisation 
of the expressive power of the Calculus of Constructions into three features: 
polymorphism, type eonstruetors, and dependent types: 



— (*, *) is the basic rule that forms types. All type systems of the Cube have 
this rule. 

— (□,*) is the rule that takes care of polymorphism. Girard’s System (also 
known as A2) is the weakest system on the Cube that features this rule. 

— (□, □) takes care of type constructors. The system Aw is the weakest system 
on the Cube that features this rule. 

— (*,□) takes care of term dependent types. The system AP is the weakest 
system on the Cube that features this rule. 

Figures 1. . . 3 illustrate the various systems of the Cube. 

Many other well-known type systems, like Automath [18], LF [11], and 
ML [17] can be more or less related to one of the systems of the Barendregt 
Cube. However, the relations between systems from “practice”, and systems of 
the Cube are not always perfect. Here are some examples illustrating this point: 



Example 1 (Automath) All the Automath systems have a relatively re- 
stricted typed A-calculus. But they are more expressive than their A-cal cuius 
suggests at first sight. This is due to a strong parameter mechanism. Even if 
one removes the typed A-calculus from Automath, a quite expressive system 
“PAL”, fully based on parameters, remains. See [18]. On the other hand, both 
Aut-68 and Aut-QE have been related to the Cube. But the corresponding 
Cube-systems are too weak to properly describe these AuTOMATH-systems (see 
below). We will be able to place both Aut-68 and Aut-QE on our refined Cube. 
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Example 2 (LF) The system LF (see [11]) is often described as the system 
XP of the Barendregt Cube. However, Geuvers [9] shows that the use of the 
i7-formation rule (*,□) is very restricted in the practical use of LF. We will 
see that this use is in fact based on a parametric construct rather than on a 
i7-formation rule. Here again, we will be able to find a more precise position of 
LF on the Cube which will be the center of the line whose ends are A^- and XP. 

Example 3 (ML) In ML (see [17]), types are written implicitly a la Curry. 
For example, instead of writing Xx:A.B, one writes Xx.B and the type checker 
in ML looks for the type. It is well-known however from [4] that the implicit 
and explicit type schemes can be related. In any case, for the purposes of our 
paper, we only consider an explicit version of a subset of ML. Furthermore, we 
do not treat recursive types nor the Y combinator. In ML, one can define the 
polymorphic identity by: 

Id(a::*) = (Xx:a.x) : (a a). (1) 

But in ML, it is not possible to make an explicit A-abstraction over a : * by: 

Id = (Aa: * .Xx:a.x) : (Ila: * .a ^ a) (2) 

Those familiar with ML know that the type Ba: * .a ^ a does not belong to the 
language of ML and hence the A-abstraction of equation (2) is not possible in 
ML. Therefore, we can state that ML does not have a i7-formation rule (□,*). 
Nevertheless, it clearly has some parameter mechanism {a acting as parameter 
of Id) and hence ML has limited access to the rule (□, *) enabling equation (1) 
to be defined. This means that ML’s type system is none of those of the eight 
systems of the Cube. We will find a place for the type system of ML on our 
refined Cube. That place will be the intersection of the diagonals of the square 
(of the Barendregt Cube) whose corners are A^-, A2, Aw, and Aw (cf. Figure 5). 

The above examples show that the Barendregt Cube of [4] cannot accommodate 
well-known and practical type systems in a precise manner. In this paper, we 
refine the Barendregt Cube by extending it with a parameter mechanism. Such 
a mechanism allows the construction of terms of the form c(6 i, . . . ,6„) where 
c is a constant and 6 i, . . . .6„ are terms. In traditional typed A-cal cuius such a 
term would be written as c6i . . . 6„. This last term is constructed step by step. 
First, c gets typed, then it is applied to bi, then the result is applied to 62, and 
so on. This means that c, ch\, chih^, . . . , ch\ .. .bn are all legal terms of the 
system. Hence, the attempt to internalise the parameter mechanism into typed 
A-calculus as described above, is going too far. In the parametric situation, only 
c{b\ , . . . ,bn) is a term. Partial constructions of this term like c{b\ ,... ,bi) (for 
i < n) are not a part of the syntax. 

Adding parameters is an extension, and a useful one, since parametric con- 
structs occur in many practical systems: 

Example 4 As explained in Example 1, Automath has a parametric system. 
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Example 5 First-order predicate logic has no A-calculus. It only has parametric 
constructs. In [15] it is shown that parametric constructs make it possible to 
give a description of first-order predicate logic in type theory that is much more 
accurate than the traditional approach in typed A-calculus. 

Example 6 Parameters occur in many parts of computer science. For example, 
look at the following Pascal fragment P with the function double: 

function double (z : integer) : integer; 
begin 

double := z + z 
end; 

P could be represented by the definition 

double = (Az:Int.(z-|-z)) : (int Int). (3) 

Of course, this declaration can imitate the behaviour of the function perfectly 
well. But the construction has the following disadvantages: 

— The declaration has as subterm the type Int Int. This subterm does 
not occur in P itself. More general, Pascal does not have a mechanism to 
construct types of the form A ^ B. Hence, the representation contains terms 
that do not occur in Pascal; 

— double itself is not a separate expression in Pascal: you can’t write x : = 
double in a program body. One may only use the expression double in a 
program, if one specifies a parameter p that serves as an argument of double. 

We conclude that the translation of P as given above is not fully to the point. 
A parameter mechanism allows us to translate P in the parametric form 

double( 2 : : Int) = (z + z) : Int. (4) 

This declaration in (4) does not have the disadvantages of (3) described above. 

So for an optimal description of practical systems it may be an advantage to 
study the “mild” extension with parametric constructs only. 

In Section 2, we give a short description of the Barendregt Cube. In Section 3, 
we extend the syntax of the Cube with parametric constructs, and propose types 
systems that can type these new constructs. In Section 4 we show that the 
proposed extension in fact leads to a refinement of the Barendregt Cube: it 
is split into eight smaller cubes. Section 5 places systems like LF, ML, and 
Automath in the Refined Barendregt Cube. We conclude in Section 6. 



2 The Barendregt Cube 

In this section we shortly repeat the definition of the systems in the Cube. For 
background information the reader may consult [4]. 
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Fig. 1. Different type formation conditions 




Fig. 2. The Barendregt Cube 
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Calculus of Constructions; [8] 



Fig. 3. Systems of the Barendregt Cube 
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Definition 7 (Terms) Let V be a set of variables. The set T of terms is defined 
by the following abstract syntax: T ::= * | □ | V | XV:T-T \ UV-T-T \ TT- 

Definition 8 (Contexts) A context is a finite (and possibly empty) list 

x\ : Ai, . . . jXn - An (shorthand: ~x'.A) of declarations of typed variables where 
Xi has type A,. The set {x\, . . . ,a;„} of distinct variables is called the domain 

DOM ^:A^ of the context. The empty context is denoted (). We use F, A as 

meta-variables for contexts. 

Definition 9 (Systems of the Barendregt Cnbe) Let R be a subset of 
{(*, *), (*, □), (□, *), (□, □)} such that (*, *) e R. The type system AR describes 
in which ways judgments F \-ji A : B (or T h A : R, if it is clear which R is 
used) can be derived. F \- A : B states that A has type B in context F. The 
typing rules are inductively defined as follows: 



(axiom) 


()!-*:□ 




(start) 


r h A : s 
F, x:A h a; : A 


X ^ DOM (R) 


(weak) 


ThA:R FhC :s 

F,x:C 'r A-.B 


X ^ DOM (R) 


(.n) 


F \- A-. s\ F, x:A \- B : S 2 

F h {Bx-.A.B) : S 2 


(S1,S2) G R 


(A) 


F,x-.Ahb-.B F h {Bx-.A.B) ■. s 

F h {Xx-.A.b) : {Bx-.A.B) 




(appl) 


Fh F -. {Bx-.A.B) Fh a-. A 

F h Fa : B[x:=a] 




(conv) 


F\- A-. B F\- B' -. .3 R =/3 R' 




R h A : R' 





There are eight different possibilities for R leading to the systems in Figure 1. 

The dependencies between these systems can be depicted in the Barendregt 
Cube (see Figure 2). Furthermore, the systems in the Cube are related to other 
type systems as is shown in the overview of Figure 3 which is taken from [4] . 

3 Parameters 

We extend the eight systems of the Barendregt Cube with parametric constructs. 
Parametric constructs are of the form c(bi, . . . , bn) where 6i, . . . , are terms 
of certain prescribed types. Just as we can allow several kinds of i7-constructs 
(via the set R) in the Barendregt Cube, we can also allow several kinds of 
parametric constructs. This is indicated by a set P, consisting of tuples (si,S 2 ) 
where si,S 2 G (sijS 2 ) G P means that we allow parametric constructs 

c{b\ ,bn) : A where b\,. . . ,bn have types Ri , . . . , R„ of sort si , and A is of 
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type S2- However, if both (*,52) G P and (tII,S2) G P then combinations of 
parameters are possible. For example, it is allowed that Hi has type *, whilst 
B2 has type □. 

First we describe the extended syntax. 

Definition 10 The set Tp of parametric terms is defined together with the set 
jC-v of lists of variables and the set Cp of lists of terms as follows: 

Tp::=V\S\ C{Ct) \ TpTp \ XV-.TpTp \ nV-.Tp.Tp] 

Ct ::= 0 I (Tt, Tp)- 

where, as usual, V is a set of variables, C is a set of constants, and S = {*, □} is 
a set of sorts. Formally, lists of terms are of the form (. . . ((0, Ai), ^2) • • • ^n)- 
We usually write {A\, . . . , An) or even Ai, . . . , In a parametric term of the 
form c(bi , . . . , bn), the subterms 61, . . . , are called the parameters of the term. 

Let ~x'.A denote x\-.Ai, . . . We extend the usual definition of fv(A), the 

set of free variables of a term A, to parametric terms: 

Fv(c(ai,...,a„)) = U”=i Fv(aj); 

Convention 11 Names of bound variables and constants will always be chosen 
such that they differ from the free ones in a term. 

Hence, we do not write (Ax:A.x)x but (Ay:A.y)x. 

We extend the definition of substitution of a term a for a variable a; in a 
term b, b[x:=a], to parametric terms, assuming that x is not a bound variable of 
either b or a: 

c(bi, . . .,bn)[x:=a] = c(bi[x:=a], . . . ,bn[x:=a\); 

Definition 12 Given the set of parametric terms, we define the set Cp of para- 
metric contexts (which we denote by T, T', . • • ) and the set Tp of lists of variable 
declarations as follows: 

Cp ::= 0 I {Cp,V-.Tp) I {Cp,C{Cv):Tp) 

Cd ::= 0 I {Cd,V:Tp). 

Notice that Cp C Cp: all lists of variable declarations are contexts, as well. 
Now we extend the typing rules of the Cube as follows: 



Definition 13 (The Barendregt Cnbe with parametric constants) Let 

R be as in Definition 9 and let P be a subset of {(*, *), (*, □), (□, *), (□, □)}, 
such that (*, *) e P. The judgments that are derivable in ARP are determined 
by the rules for AR of Definition 9 and the following two rules where A = 
xi'.Bi,... ,Xn-Bn and /A* =xi:Bi,.. . , a;j_i :Hj_i : 



(C-weak) 




r\-b: B r, Aj\- Bj-. Sj B, A \- A: s , oi c p 

r,c{A) : A\-b : B 

ri,c{A):A,r2 h bi:Bi[xj:=bj]%\ {i = l,.. . ,n) 
ri,c{A):A,r2 \- A:s (if n = 0) 

ri,c(A):A,r2 h c(bi, ...,bn) : A[xj:=bj\]^-^ 



(C-app) 
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where the c that is introduced in the C-weakening rule is assumed to be /"-fresh. 

At first sight one might miss a C -introduction rule. Such a rule, however, is 
not necessary, as c (on its own) is not a term, c can only be (part of) a term in 

the form c(bi, . . . ,bn), and such terms can be typed by the (C-app) rule. 

Constant weakening (C-weak) explains how we can introduce a declaration 
of a parametric constant in the context. The context A indicates the arity of the 
parametric constants (the number of declarations in A ) , and of which type each 
parameter must be (xj : Bj in A means the j-th parameter must be of type Bj). 

The extra condition /"i , c(zi):A , /2 h A : s in the (C-app) for n = 0 is 
necessary to prevent an empty list of premises. Such an empty list of premises 
would make it possible to have almost arbitrary contexts in the conclusion. The 
extra condition is needed to assure that the context in the conclusion is a legal. 

A term a is legal (with respect to a certain type system) if there are B, b such 
that either TI-a: 6 or/"l- 6 :ais derivable (in that type system). Similarly, a 
context r is legal if there are a, b such that F \- a : b. 

The parametric type system of Definition 13 has similar meta-theoretical 
properties as the systems of the Barendregt Cube. We list them below. The 
proofs are similar to those of the Barendregt Cube (see [14]). 

Lemma 14 Assume F \- b : B. Then DOM (6) , DOM {B) C dom {F); 

Lemma 15 (Generation Lemma) 

F If F \- s : C then s = *, C =is □ and if C ^ O then F \- C : s' for some sort 
s' . 

2. If r \- X : C then there is s G S and B =a C sueh that F \- B : s and 

(i:B) e F; 

3. If F \- {Hx'.A.B) : C then there is (si,S 2 ) G R sueh that F \- A ■. s\, 
r,x:A \- B : S 2 and C =is S 2 ; 

4 . If F \- (Xx:A.b) : C then there is s G S and B sueh that F h (IIx:A.B) : s; 
r,x:A \- b : B; and C =^3 {Fix'. A. B); 

5. If F \- Fa : C then there are A,B sueh that F \- F : {FIx:A.B), F \- a : A 
and C =i 3 B[x:=a\. 

6 . If F \- c(bi , . . . , bn) ■ D then there exist s, A = xi : Bi, ... ,Xn ■ Bn and 
A sueh that F \- D =p A[xj:=hj]f^^, and F h hi:Bi[xj:=bj]'~}^. Moreover, 
F = Fi,c(A) : A, F 2 and Fi, A \- A : s. Finally, there are Si £ S sueh that 
r, Ai\- Bi ■. Si and (sj, s) G P. 



Lemma 16 (Correctness of Types) If F A : B then B = s or F B : s 
for some s G S. 

Lemma 17 (Snbterm Lemma) If A is legal and B is a subterm of A, then 
B is legal. 

Lemma 18 (Snbject Rednction) If F A : B and A A' then F \- A' : B . 
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Lemma 19 (Unicity of Types) If F \- A ■. B\ and F A : B 2 , then B\ =p 
B2- 

Theorem 20 (Strong Normalisation) If F \~ A : B then A and B are 13- 
strongly normalising, that is: any P -reduetion path of A or B is finite. 

4 The Refined Barendregt Cube 

The systems of Definition 13 have six degrees of freedom: three for the possible 
choices of (*,□), (n,*) and (□,□) G R and three for the possible choices of 
(*, □), (□, *), and (□, □) G P. However, these choices are not independent since 
constructs that can be made with P-rule (si,S 2 ) can be imitated in a typed 
A-calculus with R-rule (si,S 2 )- This means that the parameter-free type system 
with R = {(*,*),(*,□)} is at least as strong as the type system with parameters 
with the same set R, but with P = {(*,*),(*,□)}. We make this precise in 
Theorem 26. 

The insight of Theorem 26 can be expressed by depicting the systems with 
parameters of Definition 13 as a refinement of the Barendregt Cube. As in the 
Barendregt Cube, we start with the system A^-, which has R = {(*,*)} and P = 
{(*,*)}. Adding an extra element (si , S 2 ) to R still corresponds to moving in one 
dimension in the Cube. Now we add the possibility of moving in one dimension in 
the Cube but stopping half-way. We let this movement correspond to extending 
P with (si,S 2 )- This “going only half-way” is in line with the intuition that In- 
formation with (si,S 2 ) can imitate the construction of a parametric construct 
with (si,S 2 )- In other words, the system obtained by “going all the way” is at 
least as strong as the system obtained by “going only half-way” . 

The refinement of the Barendregt Cube is depicted in Figure 4. We now make 
the above intuition that “R can imitate P” precise. 

Definition 21 Consider the system ARP. We call this system parametrieally 
eonservative if (si,S 2 ) G P implies (si,S 2 ) G R. 

Let ARP be parametrically conservative. In order to show that the parameter- 
free system AR is at least as powerful as ARP, we need to remove the parameters 
from the syntax of ARP. To do so, we replace the parametric application in a 
term c(bi, . . . , 6„) by function application cbi, . . . , bn- 

Definition 22 Define the parameter-free translation {t} of a term t G Tp by: 
{a} = a if a = X or a = s; 

{c(6i, . . .,&„)} = c{6i) • • • {bn} ; 

{ab} = {a} {b} ; 

{Ox-.A.B} = Ox:{A} .{B} if O is A or If 

Definition 23 We extend the definition of {_} to contexts: 

{()} ^ 0 ; 

{F,x-.A} = {F},x-.{A}; 

{F,c{Ay.A} = {F},c{y.{U^-A}. 




384 F. Kamareddine, T. Laan, and R. Nederpelt 



.(□,*) 6 R 
,(□,*) 6 P 




^(0,0) 6 R 
'(□,□) 6 P 









Fig. 4. The refined Barendregt Cube 

Here, A = x\ : Bi, ... ,Xn ■ and is shorthand for : Bi.A. 

To demonstrate the behaviour of {_} under /^-reduction, we need a lemma 
that shows how to manipulate with substitutions and {_}. The proof is straight- 
forward, using induction on the structure of a. 

Lemma 24 For a,b £ Tp : {a[x:=b]} = {a} [x:= {b}]. Kl 

The mapping {_} maintains /^-reduction: 

Lemma 25 a a' if and only if {a} {a'}- 

Proof: Follows easily by induction on the structure of a, and Lemma 24. Kl 

Now we show that {_} embeds the parametrically conservative ARP in the 
parameter-free AR: 

Theorem 26 Let ARP be parametrieally eonservative. If F I-rp a : A then 
{T} hR {a} : {A} . 

Proof: Induction on the derivation of F I-rp a-. A. By Lemma 24, all cases are 
easy except for (C-weak). So: assume the last step of the derivation was 

r l~Rp b : B r,Aj Frp Bj : Sj F,A Frp A : s 
F,c{Ay.A£Rpb-.B 



( si , s ) G P . 
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By the induction hypothesis, we have: 

{r}h^{b}-.{B}; (5) 

(6) 

(7) 

ARP is parametrically conservative, so (sj,s) G J? for i = 1, . . . ,n. Therefore, 
we can repeatedly use the i7-formation rule, starting with (7) and (6), obtaining 

( 8 ) 



Notice that nr=i {Bi} ■ {^} = {fl A. A}. Using (C-weak) on (5) and (8) gives 
{r},c():{nAA}hR{6}:{R}. K 



5 Systems in the Refined Barendregt Cube 

In this section, we show that the Refined Barendregt Cube enables us to com- 
pare some well-known type systems with systems from the Barendregt Cube. In 
particular, we show that Aut-68, and Aut-QE, LF, and ML, can be seen as 
systems in the Refined Barendregt Cube. This is depicted in Figure 5 on page 
14, and motivated in the three subsections below. 

5.1 Automath 

The AuTOMATH-systems (see [18]) all heavily rely on parametric constructs. 

1 ) Aut-68: The typed A-cal cuius of one of the most elementary systems of Au- 
tomate, Aut-68, is relatively simple and corresponds to A^-: it has only (*, *) 
as a i7-formation rule. This should suggest that Aut-68 has comparable expres- 
siveness A^-. But for the parametrical constructions there are no limitations in 
Aut-68 whose parameter mechanism has the following features: 

— A line (T; A:; pn; type) in a book is nothing more that the declaration of a 
parametric constant k{r):*. There are no demands on the context B, and 
this means that for a declaration x:A G T we can have either A = type (in 
Cube-terminology: A = *, so A : □) or A:type (in Cube-terminology: A : *). 
We conclude that aut-68 has the parameter rules (*, □) and (□, □); 

— Similarly, lines of the form (T;A:;pn;A 2 ) where A 2 :type, represent para- 
metric constants that are constructed using the parameter rules (*,*) and 
(□,*). 

This suggests that aut-68 can be represented by the parametric system with 
R = {(*^ *)| and P = {*, □} X {*, □}. The Aut-68 system can be found in the 
exact middle of the refined Barendregt Cube. 

2) Aut-QE: Something similar holds for the more extensive system Aut-QE. 
This system has an extra i7-formation rule: (*,□) additionally to the rules of 
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Aut-68. This means that for representing this system, we need the i7-formation 
rules R = {(*,*),(*,□)}, and parametric rules (si,S 2 ) for si,S 2 G This 

system is located in the middle of the right side of the Refined Barendregt Cube, 
exactly in between AC and AP. 

3) Pal: It should be noted that the Automath languages are all based on 
two concepts: typed A-calculus and a parameter/definition mechanism. Both 
concepts can be isolated: it is possible to study A-calculus without a parame- 
ter/definition mechanism (for instance via the format of Pure Type Systems or 
the Barendregt Cube of [4]), but one can also isolate the parameter /definition 
mechanism from Automath. One then obtains a language that is called Pal, 
the “Primitive Automath Language” . It cannot be described within the Refined 
Barendregt Cube (as all the systems in that cube have at least some basic A- 
calculus in it) , but it can be described as a system with the following parametric 
specification: R = 0, P = {(*, *), (*, □), (□,*), (□, □)}. 

This parametric specification corresponds to the parametric specifications 
that were given for the Automath systems above, from which the i7-formation 
rules are removed. 

5.2 LF 

Geuvers [9] initially describes the system LF (see [11]) as the system AP of the 
Cube. However, the use of the i7-formation rule (*, □) is quite restrictive in most 
applications of LF. Geuvers splits the A-formation rule in two: 

r,x:A\-M-.B r \- Rx-.A.B ■. * 

r h Xox:A.M : Bx.A.B ’ 

r^x-.AhM-.B Bh Bx-.A.B -U 

r h \px:A.M : Bx.A.B ' 

System LF without rule {\p) is called LF“. /1-reduction is split into /lo-reduction 
and /Ip-reduction: 

{Xox:A.M)N M[x:=N\- 

{Xpx:A.M)N M[x:=N]. 

Geuvers then shows that 

— If M : * or M : A : * in LF, then the /Ip-normal form of M contains no Ap; 

— If T Plf M : A, and T, M, A do not contain a Ap, then F Plf- M : A; 

— If r \- M : A{: *), all in /Ip-normal form, then F Plf- M : A{: *). 

This means that the only real need for a type Bx.A.B : □ is to be able to 
declare a variable in it. The only point at which this is really done is where the 
bool-style implementation of the Propositions-As-Types principle pat is made: 
the construction of the type of the operator Prf (in an unparameterised form) 
has to be made as follows: 

prop:* h prop: * prop:*, a::prop h *:□ 

prop:* h (i7a::prop.*) : □ 
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In the practical use of LF, this is the only point where the i7-formation rule 
(*,□) is used. No Ap-abstractions are used, either, and the term Prf is only 
used when it is applied to a term p:prop. This means that the practical use 
of LF would not be restricted if we introduced Prf in a parametric form, and 
replaced the i7-formation rule (*, □) by a parameter rule (*, □). This puts (the 
practical applications of) LF in between the systems A^- and AP in the Refined 
Barendregt Cube. 

5.3 ML 

In ML (cf. [17]) one can define the polymorphic identity by (we use the notation 
of this paper, whereas in ML, the types and the parameters are left implicit): 

Id(a::*) = (Axia.x) : (a a). 

But we cannot make an explicit A-abstraction over a:*. That is, the expression 
Id = (Aa: * .Xx'.a.x) : (Ua: * .a ^ a) 

cannot be constructed in ML, as the type IIa:*.a a does not belong to the 
language of ML. Therefore, we can state that ML does not have a i7-formation 
rule (□, *), but that it does have the parametric rule (□, *). 

Similarly, one can introduce the type of lists and some operations by: 

List(a::*) : 

nil(a::*) : List(a:); 

cons(a::*) : a —> List(a:) —> List(a:), 

but the expression Ua:*.* does not belong to ML, so introducing List by 

List : Ua:*.* 

is not possible in ML. We conclude that ML does not have a i7-formation rule 
(□, □), but only the parametric rule (□, □). Together with the fact that ML has 
a i7-formation rule (*,*), this places ML in the middle of the left side of the 
refined Barendregt Cube, exactly in between A^- and Xw. 

6 Conclusion 

In this paper, we observed that many existing type systems do not fit exactly in 
the Barendregt Cube. In particular, we explained that previous attempts to de- 
scribe LF and Automath were not very successful!. We noted that Automath 
uses parameters heavily, and that there are some types that are only used in 
special situations by LF and that those types and situations could be covered 
by parameters. In addition, we considered an explicitly typed version of ML and 
noted that there too, ML cannot occupy any of the corners of the cube. The 
reason being that, ML (as well as LF and Automath) allows i7-types, but not 
all of them. In any corner of the Cube, as soon as an abstraction of a sort is 
allowed, all abstractions of that sort are allowed too. 
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Fig. 5. LF, ML, Aut- 68, and Aut-QE in the refined Barendregt Cube 



Our above reasoning led us to propose a refinement of the Cube where not 
only the eight corners can be inhabited, but also points half way between these 
corners. This way. Automath, LF, and ML find more accurate locations on 
the Cube to represent their typing systems. We described an extension of the 
Barendregt Cube with parameters. This is more a refinement than an extension, 
as new systems that are introduced can be depicted by dividing the traditional 
Barendregt Cube into eight sub-cubes. This is due to the fact that parametric 
constructs can be imitated by constructions of typed A-calculus (see Theorem 26) 
but not the other way around. 

We showed that our refinement makes it possible to: 

— Give a better description of practical type systems like LF and ML than the 
systems in the usual Cube. 

— Position systems that could not be placed in the usual Cube (several 
AuTOMATH-systems) . 

This makes it possible to give a more detailed comparison between the expres- 
siveness of several type systems. 

Not only can we add parameters to the Barendregt Cube resulting in an 
elegant and more refined hierarchy of systems, but we can follow a similar con- 
struction to the more generalised notion of Pure Type Systems (PTSs) (see [4]). 
In addition, we can add definitions (see [5, 22]) and parametric definitions to our 
above refinement of the Cube and even to the refinements of PTSs, giving a very 
general hierarchy that can express more precisely and elegantly many practical 
systems and that give a full description of Automath. 
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